Pool reuse: measured memory saving, hot-path repair and actual cost

This is a dated qualification record for PR #135, not a released-default claim. At the checked head 2ca9a3aa73e3b3284f9db4ad9f8cdb2ca0aeab8d, GitHub reports open, non-draft, unmerged. Its base is f60f8de605cbbdce2f22e4bc3489e1c1487dcb59. The candidate is Ready for validation; game validation has not been declared complete.

Mechanism and scope

The candidate reuses fully empty mapped slab backing when another size class needs a refill. Its purpose is to avoid retaining a separate population of empty backing for each class. It preserves live addresses, allocation classes/header semantics, query capacity and ordinary versus reserved domains. It does not implement a new broad class ladder, change the minimum stack, add workers, or shrink the file cache.

The latest focused repair removes redundant predecessor-pointer writes when a free-list successor becomes the head. A head is identified by its identity in the list, rather than assuming that its unused predecessor field must be zero. Non-head predecessor links remain valid; publication repairs a former head before it becomes a non-head. Fragmented removal retains a real fallback. This describes owned-source invariants rather than prescribing a proprietary allocator implementation.

Artifact binding

Field	Current candidate
Product head	2ca9a3aa73e3b3284f9db4ad9f8cdb2ca0aeab8d
Reconstructed source tree	131874eb1561e7ae431fa6992f70e87cab2286ec
Release 64 firmware SHA 256	05f385c06724cdf553340fcb0cfb8b42636802b0659e49fb2faf508ac3bbc92d
Latest ordered patch	0061-pool-head-link-writes.patch
Comparison diagnostic A	Previous maintained span repair, freshly relinked; not plain main
Diagnostic A source tree	baf8e24b04ccf4a2a62448d077ed3fc6180dcf41
Diagnostic A firmware SHA 256	d4220a58c93f99b0975d7af3cbb6f03469644511ee34692cf7618b99bc6f1b3a

Old game measurements stay attributed to their tested old head. The current release title comparison uses plain main versus the new candidate, whereas the allocator-cost diagnostic isolates the latest head-link repair against the prior maintained span repair. Those are different questions and cohorts.

Memory and correctness observations

Check	Established result	Limit
Production-body mixed lifetime replay	2,093 events; settled 86→70 pages; peak 214→198;439 live objects retain correct contents/capacity	Controlled host replay, not all title patterns
Ordinary 64 public allocation/lifetime guest	576 allocations,40 thread lifetimes; normal exit; final 16,068 available /316 unavailable pages	Not a whole-game memory peak or a fresh complete private-owner census
Savings against retained main checkpoint	16 pages /64 KiB retained	Post-activity saving; not a cold-boot saving claim
Production host checks	Ordinary/upper-reserved, arbitrary unused head predecessor, fragmented detach and domain checks pass under ASan/UBSan	Leak checking disabled in the ptrace fixture environment
Maintained public pool checks	160 active size/interior/free-boundary checks pass	Focused allocation contract coverage
Product tests	105 tests,3 explicit skips, no failures	Test count does not measure game performance
Source review	No critical/important finding; reviewed predecessor consumers/publication/fallback	Minor explicit allocation-failure→reclaim→supplier-retry fixture recommendation remains

The source repair removes work in the generated warm path. That fact is distinct from a measured speed improvement.

Eight-run release Deck allocator diagnostic

The order is ABBA followed by BAAB, four samples per arm. Same compiler/configuration, installed xemu, public diagnostic guest, ordinary 64 MiB and fresh process. All eight runs report errors 0, matching checksum 1,560,576 and 24,576 allocations each. Guest PM-counter intervals are neither host-exclusive CPU cycles nor game frame times.

Values below are equal-weight means of the four per-run summaries. The initial round is retained separately and excluded from repeated-path statistics. Percentiles describe allocation bursts, not frame-time samples.

Repeated operation metric	Prior maintained span repair A	New head-link repair B	B versus A
Warm allocation interval sum	965.406 µs	973.333 µs	+0.821%
Warm free interval sum	816.716 µs	774.043 µs	−5.225%
Mixed allocation interval sum	8,279.034 µs	9,033.963 µs	+9.119%
Mixed free interval sum	5,409.413 µs	5,775.617 µs	+6.770%
Mean per-run mixed allocation-burst p 99	105.497 µs	170.144 µs	+61.278%

Mixed allocation sums worsen in both orders: +11.469% ABBA, +6.672% BAAB. One B run has a 328 µs burst p 99. The absolute extra mixed allocation interval is approximately 755 µs across 20,608 timed repeated allocations. These observations establish no native allocator speed gain from the latest repair. They must remain recorded even if final title behavior is acceptable.

A lower instruction count cannot erase the timing result. Conversely, this synthetic burst result alone does not establish a noticeable game regression. Title cadence/tails, functionality and the frequency of the changed path decide that separate question.

Conker menu attribution: useful negative result

A separately pinned entry/direct-return diagnostic recorded five allocator boundaries in the established animated military bar-menu scene. Earlier classification of this scene as an unskipped movie was incorrect and has been corrected. The effective emulator memory setting was 128 MiB with release 64 firmware: this is discovery, not ordinary 64 qualification.

Tracked operation	Calls fully inside 45.762-second window	Summed covered elapsed intervals	Longest covered interval
Pool allocation	735	2,673 µs	304 µs
Pool free	731	2,589 µs	290 µs
Pool backing-page allocation	0	0	Not applicable
Empty slab detach	0	0	Not applicable
Pressure reclamation	0	0	Not applicable

The allocation/free interval union is 5,262 µs /0.011499% of window wall time. No covered call reaches 1 ms; no dropped records, boundary errors or outstanding tracked calls are reported. Inclusive elapsed intervals include children, blocking, interrupts and descheduling. Indirect aliases/tail or nonlocal exits remain coverage limits; this is not CPU self-time.

This capture does not support blaming refill work for that menu's frame hitches. It also does not cover race loading, memory pressure, reset or other titles. The correct next step is to test the actual lifetime/pressure boundary, rather than adding more optimizations to an inactive menu path.

Provenance mistake and prevention

An earlier setup pointed its symbol manifest into a mutable build directory that had been reused by a rejected experiment. It was discarded before accepting attribution. The restored source was rebuilt; matching BIOS/PE artifacts were frozen, and the accepted live entry/return opcode checks matched. Future capture setup must bind to the frozen pair, not a remembered filename in a reused build directory.

Acceptance and remaining boundaries

Release game validation uses the established authored inputs and ordinary 64 configuration. No pre-measurement wait or acceleration is added to PGR 2. Scene checks distinguish the intended parked/menu location from loading/flyover. Driver-cache, thermal and animation-phase limits remain visible; guest flip cadence is not host-presented FPS.

An isolated allocator metric can worsen while a memory candidate remains useful. A repeatable total-cadence loss, significant game p 95/p 99 increase, failed allocation contract, incorrect rendering or lost functionality needs diagnosis. Lower CPU use alone does not justify poorer useful progress; higher CPU accompanying higher useful cadence is not automatically a regression.

No partial first-pair game improvement is claimed here. The complete balanced title campaign and actual scene review remain the gate. Issue #134 stays open until the accepted repair lands; #106 continues tracking the remaining parity gap.

See the detailed code/evidence update on PR #135. Raw captures and experimental binaries remain outside product main and the wiki.