Parent: #461 Discovered by: #844, #845
Problem
The native representative attribution gate deterministically rejected shared 2-lane representative_weak_collections at warmup. Backing accounting was exact (60,614,174 added - 36,184,922 released = 24,429,252 current), and allocation-kind counts decomposed exactly, but GC-cell lifetime bytes did not: 28,463,893 acquired < 33,871,815 released.
Two source paths were omitted:
GcCellBacking.allocateCellBatchreturned fresh or reused owned slots without calling the runtime attribution profiler. Later sweep paths did record their frees.- Delegated GC-side storage resize/remap growth and shrink changed the eventual free size without updating acquired/released lifetime byte totals.
Scope
- Attribute every successfully returned batched owned slot with its exact bucket size and fresh/reused origin.
- Attribute successful delegated resize/remap growth and shrink deltas without manufacturing allocation/free operation counts.
- Preserve the existing batch lock boundary, parallel allocation-pressure accounting, and allocator semantics.
- Do not estimate from requested aggregate sizes or weaken the
gc_cell_bytes >= gc_cell_freed_bytespublication invariant. - Add focused mixed fresh/reused, partial-batch, resize, and remap lifetime tests.
Acceptance
- Batched fresh and reused allocations increment total count/bytes and exactly one kind per returned slot.
- Partial batches account only slots actually returned.
- Successful delegated growth/shrink/remap updates byte lifetime while allocation/free counts remain exact.
- Batched and delegated releases never exceed attributed lifetime acquisition bytes.
- Focused Debug and TSan tests pass.
- Representative attribution quick collection completes end to end with all existing allocation gates unchanged.
Security boundary
Profiler evidence is fail-closed. The repair accounts the real allocator lifecycle at its source; suppressing the invariant or clamping released bytes would conceal allocator/GC defects.