ReviewOS

zig-utils/zig-js

Perf: reclaim dead nursery backing in whole slab runs

#427
Closed chris opened this 9 days ago ·
9 days ago

Parent: #97 Follows: #426 Dependency experiment: zig-utils/zig-gc#42

Disposition: rejected and fully reverted

The exact 8b271b34 phase profile showed nursery sweep dominating the eight-lane cooperative pause, so this issue tested whether clearing and recycling wholly dead 64 KiB backing chunks could remove the per-cell cost. A correct prototype consumed zig-gc's address-ordered dead-run contract, batch-unpublished complete runs before finalization, reset full-chunk ownership/free bitmaps after finalization, and retained the exact partial-live fallback.

Completed experiment

  • Implement an explicit owned-backing capability over the zig-gc dead-run prototype.
  • Preserve classification-before-finalizer ordering, stable realm ownership, live/free accounting, relocation, reuse, teardown, and partial-live fallback in focused tests.
  • Prove the complete-chunk path executes in the cooperative nursery regression.
  • Run seven alternating fresh-process pairs per 1/2/4/8 lane against exact parent 8e4580cf + zig-gc 529e0f2, with unchanged checksums and collector invariants.
  • Apply the retain/revert gate: eight-lane sweep improved only 0.7%, wall time regressed 0.9%, and the candidate won 2/7 pairs; one lane regressed 1.1%.
  • Fully revert both the uncommitted zig-js activation and zig-gc prototype (64d2660 reverted by 88ea254).
  • Publish raw samples and the verdict.
  • Leave README benchmark scores unchanged.

ReleaseSafe/TSan downstream retention gates were deliberately not run after the earlier performance gate rejected the candidate; no downstream code remained to certify. zig-gc's prototype itself passed normal and suppression-free TSan before measurement.

9 days ago

Closed as a measured negative result. Exact checksums and accounting passed, but the required performance gate failed; both activations were fully reverted and raw/summary evidence is committed at 91485cb0.

Sign in to comment on this issue.