ReviewOS

zig-utils/zig-gc

Perf: tune the default nursery for allocation throughput

#21
Closed chris opened this 8 days ago ·
8 days ago

Parent consumer: zig-utils/zig-js#62 Related: zig-utils/zig-js#97

Problem

The default and minimum nursery are both fixed at 4 MiB. The current zig-js bounded object-allocation comparison reclaims almost all young cells, yet sampling shows minor collection and young-prefix sweep remain dominant costs:

  • direct profile top-of-stack: collectYoung 79 samples, sweepPhaseLocked 61, reusable-slot lookup 43 out of 536;
  • eight independent contexts: collectYoung 945, sweepPhaseLocked 952, reusable-slot lookup 120 in the sampled process;
  • current fair medians: zig-js 116.08 ms vs JSC 113.92 ms direct, and 293.37 ms vs 166.00 ms at eight warmed independent contexts, with exact checksums.

The current adaptive policy cannot grow a near-zero-survival nursery above its 4 MiB minimum, so short-lived allocation repeatedly pays root publication and sweep setup even when more nursery capacity would reduce total CPU time.

Scope

  • measure 4/8/16/32 MiB nursery policies on bounded ephemeral and mixed-survival graphs;
  • choose a general default/minimum or survival-aware floor from paired wall-time, collection-count, pause, memory, and promotion evidence;
  • keep the collector non-moving and preserve remembered-owner/target, weak, finalization, and OOM semantics;
  • avoid benchmark-only configuration or engine-specific source changes;
  • expose/document enough policy evidence that consumers can validate the choice.

Acceptance

  • materially reduce direct and parallel-independent allocation wall time;
  • do not regress retained-graph nursery cases or unboundedly inflate retained memory;
  • pass zig-gc unit and TSan suites;
  • land the consumer benchmark/README update under a linked zig-js issue.
8 days ago

Closing the constant nursery-size experiment without a merge. The zig-js consumer screen found 8 MiB helped some direct samples but regressed multi-context throughput, while 2 MiB sacrificed direct throughput and was inconsistent at eight lanes. The repository remains at the existing 4 MiB policy; the accepted independent improvement is batched sweep accounting in #23.

Sign in to comment on this issue.