[Cache] fix memory leak when using PhpArrayAdapter #34839
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thanks to @adrienfr, I've been able to understand what causes this massive memory leak when using

PhpArrayAdapter
:When tests run, a new kernel is booted for each test case. This means a new instance of
PhpArrayAdapter
is created, which means it loads its state again and again usinginclude
for e.g.annotations.php
in this example.The first obvious thing is that we see this doing
compile::*
: this means PHP is parsing the same file again and again. But shouldn't opcache prevent this? Well, it's disabled by default becauseopcache.enable_cli=0
. To prove the point, here is a comparison with the same tests run withphp -dopcache.enable_cli=1
. The comparison is swapped, but you'll get it:But that's not over: because of https://bugs.php.net/76982 (see #32236 also), we still have a memory leak when the included file contains closures. And this one does.
This PR fixes the issue by storing the return value of the include statement into a static property. This fits the caching model of
PhpArrayAdapter
: it's a read-only storage for system caches - i.e. its content is immutable.