ReviewOS

zig-utils/zig-js

Perf: batch fresh-object barriers in allocation loops

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

Parent: #62 Dependency: zig-utils/zig-gc#13

Evidence

After #88, the fair direct object_churn row is 223.980 ms in zig-js versus 131.320 ms in system JSC, a 1.706x remaining gap with exact checksum 1030552128.

The current symbolized profile attributes 135 exclusive samples to Heap.writeBarrierFromManaged. The structural quick loop allocates a fresh managed object and stores it into the same prevalidated dense array every iteration, but repeats the exact child/owner barrier even though each quick entry is bounded to one 1024-step GC checkpoint island.

Scope

  • use zig-utils/zig-gc#13 to prepare the exact managed array owner once per checkpoint-bounded fresh-allocation batch;
  • directly publish each freshly allocated child after the existing restriction, bounds, hole, proxy/accessor, and shape guards;
  • retain the current generic barrier/store path in arena mode and for every unsupported case;
  • re-run owner preparation after each checkpoint so minor collection promotion/remembered-set clearing cannot be skipped;
  • preserve OOM publication, exact VM steps, and incremental/concurrent marking invariants.

Acceptance criteria

  • Focused GC coverage proves an old array retains fresh children across minor collection.
  • Differential quick-loop results and exact step counts remain unchanged.
  • Arena, accessor, proxy, restricted receiver, and shared-mode fallbacks remain intact.
  • Exact-parent alternating A/B shows repeatable improvement with stable checksums.
  • zig-gc and zig-js batched validation pass.
  • Retained commits reference this issue.
9 days ago

Rejected and fully reverted after exact-parent measurement; no commit was pushed.

The implementation added zig-utils/zig-gc#13 owner preparation, passed the full zig-gc suite, and passed all three focused zig-js quick-object/forced-minor/restricted-receiver tests with zero leaks. It removed the per-child exact barrier from the structural allocation loop while preserving one owner preparation per checkpoint island.

Seven alternating fresh-process pairs with three timed samples per process produced:

  • paired median change: +0.11%;
  • only 3/7 candidate wins;
  • checksum 1030552128 in every sample.

Two loaded-host outliers hurt the aggregate, but the order-balanced paired result itself is neutral and does not justify a new cross-repo API. Both worktrees are clean. The next #62 work should target the substantially larger nursery sweep/free costs.

Sign in to comment on this issue.