Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 2 commits into
base: PHP-8.2
Choose a base branch
from

Conversation

arnaud-lb
Copy link
Member

@arnaud-lb arnaud-lb commented Jul 3, 2024

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.

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>
@arnaud-lb arnaud-lb changed the title Do not create a memory mapping too close to the heap Do not create a the opcache shm mapping too close to the heap Jul 3, 2024
@arnaud-lb arnaud-lb changed the title Do not create a the opcache shm mapping too close to the heap Do not create the opcache shm mapping too close to the heap Jul 3, 2024
@arnaud-lb arnaud-lb requested a review from nielsdos July 4, 2024 22:34
@arnaud-lb arnaud-lb marked this pull request as ready for review July 4, 2024 22:35
@dstogov
Copy link
Member

dstogov commented Jul 5, 2024

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants