Cache freed VM stack pages instead of freeing them immediately

[ondrejmirtes]

Disclaimer: I found out this issue when measuring performance of a giant subsystem rewrite in PHPStan, which performed better on many projects but worse on a particular one. This issue and pull request was discovered and debugged with the help of an LLM, afterwards discussed privately with Arnaud Le Blanc who told me that it's an interesting finding and worth reviewing.

A call stack whose depth oscillates across a VM stack page boundary allocates and frees a 256KB page on every oscillation: zend_vm_stack_extend() on the way down, and the immediate efree() in zend_vm_stack_free_call_frame_ex() on the way back. Every such allocation goes through zend_mm_alloc_large(), whose search for contiguous free pages degrades on a large, fragmented heap — in the worst case scanning every chunk's free-page bitmap, failing, and paying an mmap/munmap round-trip per oscillation.

Long-running processes with multi-GB heaps hit this hard. I found it profiling PHPStan analysing a large codebase in a single process (gc_disable(), multi-GB heap): 73–90% of all CPU time was in zend_mm_alloc_pages reached from the ZEND_INIT_METHOD_CALL handlers — pure VM stack page churn, no useful work.

The change

Keep up to 32 freed standard-size VM stack pages in a per-executor free list (EG(vm_stack_page_cache)) and serve zend_vm_stack_new_page() from it; flush the list in zend_vm_stack_destroy(). Details relevant to review:

• Only pages of exactly EG(vm_stack_page_size) are cached (checked on both push and pop); oversized pages — frames larger than the page size — are still freed eagerly.
• The retention ceiling is 32 × 256KB = 8MB per executor, and the cache is flushed at zend_vm_stack_destroy(), so nothing outlives the request. In practice an oscillating workload holds one or two pages.
• The cache lives in executor globals, so ZTS builds get one per thread; no shared state.
• The fast path adds one predictable branch to zend_vm_stack_new_page(); the reclaim path replaces an efree() with a list push under the same size check.

Benchmark

Isolated reproducer (gist with benchmark + reproducer): recursion to a fixed depth in a loop, with the heap optionally pre-fragmented by ~600k interleaved ~5.5KB allocations keeping every other one, so the free space is 2-page holes that can never satisfy a 64-page VM stack request. Each iteration is one full depth oscillation.

Apple M1 Pro, macOS, NTS, minimal --disable-all build of master (c621cbe27ff), 20,000 iterations per cell, µs per oscillation:

depth	master, fresh heap	master, fragmented	patched, fresh	patched, fragmented
1,500	40.0	40.1	40.1	38.5
3,000	79.0	79.7	77.5	77.0
4,500	119.5	1,846.1 (15.4×)	114.7	116.4
6,000	158.2	3,543.9 (22.4×)	152.7	154.0
9,000	331.7	7,185.8 (21.7×)	229.6	230.4

The cliff between depth 3,000 and 4,500 is where the recursion outgrows the initial VM stack page and every iteration starts paying the alloc/free cycle. With the patch the fragmented column matches the fresh column at every depth — and the deep fresh-heap case improves too (depth 9,000: 331.7 → 229.6µs), since even a fast allocator round-trip is slower than popping a cached page.

Real-workload effect: PHPStan (before it shipped its own userland mitigation), analysing the same 40 files of a large codebase single-process with the heap pre-fragmented as above: 537s → 51s wall with the patch — identical to its fresh-heap time.