Add --enable-rtld-deepbind configure flag, disable it by default except for apache

[danog]

This pull request adds an --enable-rtld-deepbind flag, which enables the use of RTLD_DEEPBIND for dlopen, and changes the default behavior of dlopen to use RTLD_DEEPBIND only when compiling the Apache SAPI.

Re: #10670, #11094

This fixes compatibility with custom allocators like jemalloc on newer glibc versions, while still retaining the old DEEPBIND behavior for apache, which seems to have been the reason why it was added.

[danog]

Might be worth backporting into 8.3, as it is technically a bugfix IMO...

[danog]

Ping? :)

[danog]

Ping @nielsdos / @cmb69

[nielsdos]

I was not a fan of the idea before and I still am not. Why do people want to change the allocator using a preload hack anyway? For almost anything request-related, PHP has its own allocator so that would bypass jemalloc or whatever you use anyway.
Also, how does this patch play with building for multiple SAPIs at the same time?
This seems like one of those configurations that will cause more trouble than it's worth tbh.

[danog]

Changing the allocator with LD_PRELOAD is pretty much the standard way it is done for jemalloc, mimalloc, and the many other allocators currently being used in production to improve performance.

I understand PHP also has its own internal custom allocator with its own memory pool, which greatly improves performance, but I don't see why should a legacy change made in 2005 to workaround some apache issues (not relevant on standalone executables like php-cli/php-fpm) completely prevent users from making use of the additional (even if small) performance improvements offered by jemalloc (on top of zend's allocator).

Users may wish to replace the allocator for the entire systems (i.e. by setting an ENV LD_PRELOAD in a docker container, affecting all applications within), and PHP would be the only major application that breaks this.

Regarding how RTLD_DEEPBIND is disabled, I do not have any strong opinions (i.e. it could even be an ini entry), but the approach in this PR is the approach recommended by @dstogov in #11094 (comment).

[danog]

Also, as a small factoid, the improvements of using jemalloc or other custom allocators instead of the system's libc malloc are non-trivial, depending on the flavor of libc being used: for example, @Bilge's ScriptFUSION project imports suffered 30% slowdowns on MUSL libc, with the zend allocator enabled; using jemalloc (on top of the usual zend allocator) restored glibc-like performance.

[Bilge]

Can confirm. Jemalloc is only fractionally slower than glibc (but it is slower) and I use it in production on Alpine to benefit from smaller images.

[danog]

Can confirm. Jemalloc is only fractionally slower than glibc (but it is slower) and I use it in production on Alpine to benefit from smaller images.

Yep, same here, I use jemalloc on my alpine MadelineProto images, because MUSL libc malloc is absolutely unusable.

PHP has its own allocator so that would bypass jemalloc or whatever you use anyway.

The zend allocator does use mmap directly, but the libc allocator can still significantly affect performance

[nielsdos]

I don't care about this enough to want to spend energy on this. But if this breaks and causes issue reports I will ignore them too.

[cmb69]

I can't say much about this (mostly working on Windows), but if MUSL's allocator is so slow, why don't they use jemalloc (or something else) in the first place?

[danog]

Well, that's a question for the MUSL libc maintainers :)

[danog]

@iluuu1994 Mind taking a look too & merging if possible?