Do not create the opcache shm mapping too close to the heap

[arnaud-lb]

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:

• A bug in malloc causes it to leak memory when falling back to mmap()
• Some shared library gets confused by either the missing [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.

[dstogov]

The goal of find_prefered_mmap_base() is to find a free mapping space close to ".text" segment.
This should allow JIT generation of "short" jumps and calls to PHP routines (one asm instruction instead of two).

This patch disables hinting in case we didn't find a big enough hole before the [heap]. Right?

Ususally, .text segment is immediately followed by .rodata, then .data and then .bss.
There is some gap between .bss and .heap. In may case - 18MB.
This is too small for opcache. So your patch just disables the hinting and leads to worse JIT code for everyone, while we see only a single issue.

I would suggest different ways to fix this:

• don't call find_prefered_mmap_base() if JIT is disabled (opcache.jit=disable)
• make use of find_prefered_mmap_base() optional (through an additional php.ini directive)

[arnaud-lb]

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 find_prefered_mmap_base() only if JIT is enabled, as suggested.

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.

[dstogov]

This will still make the JIT code worse (at least for non-PIE builds). Right?

[arnaud-lb]

No, I've essentially reverted my original change. Now the only change, in addition to the backported commit, is to use find_prefered_mmap_base() only if JIT is enabled