[staalmannen]

Measured on 9front/amd64. Section 0: 0 of 8 aligned, and every one misaligned by exactly 0x1ff000 -- 0xfedff000, 0xfebff000, 0xfe9ff000 and so on, spaced 2MB apart, each starting one page below a 2MB boundary. So segattach places on a 2MB grid, off by 4096, and zend_mm_chunk_alloc_int would trim. Sections 2 and 3 both survived, so the partial-unmap arm works on the machine as well as the host.

But three of section 0's eight mmap calls FAILED, and that is the bigger finding. Five 2MB mappings is 10MB, which is nothing, so it is not memory -- it is a limit on how many mappings a process may hold, and p9_mmap_impl spends a Plan 9 segment slot on every mapping at or above SEG_THRESHOLD. A ceiling of about five live mappings is a harder limit for php than any amount of trimming, since Zend allocates the heap in 2MB chunks.

Section 0b separates the two hypotheses, with the prediction written down first: if the limit is slots, the count is the same small number at every size and the bytes held differ by orders of magnitude for no reason; if it is address space, the count falls roughly as 1/size. The smallest of its three sizes is deliberately just under SEG_THRESHOLD, so it is malloc-backed, takes no slot, and should run to the array's end -- the control. On the host all three hit 64, which shows only that the section runs; Linux has no slot limit to find.

Section 1's over-sized mapping came back 2MB-aligned, which contradicts section 0's five and so is recorded as one sample of a size-dependent placement rule rather than generalised.

Claude-Session: https://claude.ai/code/session_01WGAwvvTwDg2yknFkmZ3qzs