https://github.com/php/php-src/pull/223

There is a major problem with doing this and why I didn't end tying into the PHP 
memory allocator. Depending upon setup, it is extremely likely to be able to hit 
memory corruption and/or mix memory allocations between modules. i.e. using 
mod_perl and mod_php will cause PHP to override the libxml memory handling 
functions (which are global) and bleed into mod_perl (or any others that are 
using libxml2) causing any number of results (crashes, security issues, etc..). 
The only way to be able to do something like this would be to make it compile 
time option which is disabled by default allowing those who know their 
environment intimately can utilize this at their own risk, Don't know if you 
want to write a patch for that or not. Otherwise I don't see any way this could 
safely be added,

Do you know of a specific case where request-local allocations could bleed into mod_perl and cause memory corruption?

I have reviewed all of libxml's global variables and ensured that they cannot be made to hold pointers to request-local allocations. The hooks are disabled at post-deactivate via a thread-local variable, so a perl request will not get request-local pointers from xmlMalloc() whether it runs in its own thread concurrently, or in the same thread as PHP but at a later time. TSRM_FETCH() should give default global variables, with local request allocation disabled, even if it is called from a thread where PHP has never been used.

Either way, I would be happy to make this configurable, off by default, since the robustness of the solution depends on details of global pointer storage in libxml which may change in the future. So my patch does introduce a maintenance burden, with a risk of dangling pointers if that maintenance is not kept up to date. I'm just not keen on having the documentation say that there are known issues with interaction with other Apache modules unless that is truly the case.

That is a very well known issues when mixed builds free and alloc same memory 
areas.

It is (almost) no problem when using libc allocation system but it is a (huge) 
problem when php uses PHP memory manager and other libc or their own mm. It leads 
to crashes, almost always.

Unassigning from me since I'm not really interested in pursuing this. I have tried to explain the risks involved, and the precautions I have taken, but the comments I have received, here and on the pull request, indicate that I have not been successful. The feature will require maintenance, and obviously if nobody understands what the patch is doing and why, then nobody will be able to maintain it.