[GIT-PULLS] [php-src] PR #23470: Cache freed VM stack pages instead of freeing them immediately

Pull Request: https://github.com/php/php-src/pull/23470
Author: 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](https://gist.github.com/ondrejmirtes/1c1bc4894e63ddcb6c58d7bfe59cdb7a)): 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.