Do not create the opcache shm mapping too close to the heap #14793
Conversation
Avoid missing possible candidates due to the large address range of the free segment. Eg, 48000000-49400000 r-xs 08000000 00:0f 39322841 segment1 7ffff2ec8000-7ffff2f49000 rw-p 00000000 00:00 0 segment2 7ffff6fae000-7ffff735c000 r-xp 00200000 08:02 11538515 /usr/local/sbin/php-fpm original code will miss the opportunity between [7ffff2ec** - 7ffff2ec8000]. Fix issue php#11265. Signed-off-by: Long, Tao <tao.long@intel.com> Signed-off-by: Dmitry Stogov <dmitrystogov@gmail.com>
|
The goal of This patch disables hinting in case we didn't find a big enough hole before the Ususally, .text segment is immediately followed by .rodata, then .data and then .bss. I would suggest different ways to fix this:
|
|
Ah, indeed in non-PIE builds there is no good candidates before the heap. I was testing a PIE build, and there is enough free space before the text segment in this case. I've updated the PR to call With the backport of a2af8ac, the function will see the free space before the text segment as a good candidate if it's large enough, so this should still fix #13775 in PIE builds when JIT is enabled. |
|
This will still make the JIT code worse (at least for non-PIE builds). Right? |
|
No, I've essentially reverted my original change. Now the only change, in addition to the backported commit, is to use |
Under some conditions we may allocate the opcache shm segment just after the heap, which prevents it from expanding. Malloc continues to work (it fallbacks to mmap()), but in #13775 this leads to a significant increase in VMA and RSS. The exact reason is unidentified, but we can make a few hypotheses:
[heap]label the fallback mmap, or by the non-contiguous heap (e.g. some code relying on heap scanning would not see the entire heap).Here I change find_prefered_mmap_base() so that it doesn't return an address too close to the end of the heap.
This fixes #13775.
I also backport a2af8ac from 8.3, otherwise no good candidate is found if all gaps before the heap are too large.