ReviewOS

zig-utils/zig-js

Perf: keep private GC scratch on the context allocator

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

Parent: #44 Related: #62, #97, #116

Problem

The object-churn profile was dominated by young collection and sweep. Eight independent private contexts also showed process-level allocator syscalls and substantially worse GC wall time than one context. Every GC heap assigned collector scratch (mark_stack, barrier/weak buffers, and related temporary lists) to std.heap.page_allocator, a policy introduced for the concurrent-marker thread even though that requirement does not apply to private contexts.

Completed work

  • Select the unbudgeted host allocator for GC scratch only when engine threads, concurrent GC, and parallel GC are all disabled.
  • Keep std.heap.page_allocator for concurrent-marker, threaded-GIL, and parallel contexts.
  • Preserve allocator lifetime and the public heap-budget boundary.
  • Add a focused identity/lifetime regression test distinguishing the private, concurrent, and threaded paths.
  • Profile and run order-balanced exact-parent A/B measurements for direct, warmed eight-context, and cold eight-context object churn.
  • Publish the clean full matrix, raw evidence, benchmark guide, and README.

Result

Runtime: ab7b08fb (perf(gc): use host scratch for private contexts (#119))

Publication: 88bd1b00 (docs(bench): publish private scratch results (#119))

Against the frozen parent runner, seven-sample order-balanced A/B improved warmed eight-context object churn by 5.2% and 6.7%, cold by 10.8% and 30.1%, and direct by 16.2% and 1.6%. Checksums were exact. A matched 10-second candidate profile contained no sampled mmap/munmap frames, versus 76 matching call-tree entries in the parent profile.

The clean publication matrix passed all 1,540 sample/checksum/timing-floor validations. Full normal tests passed 768/768 with no leak; TSan passed 767 plus one expected soak skip with no failure, leak, or sanitizer report; the docs build produced all 24 pages.

The low-battery full matrix still has independent and shared object-churn losses, owned by #62/#97/#116. This issue is complete because its scoped allocator change passed every acceptance criterion; it does not claim to complete the parent performance program.

9 days ago

Landed the accepted runtime slice in ab7b08fb (perf(gc): use host scratch for private contexts (#119)).

Private, non-threaded, non-concurrent GC heaps now allocate collector scratch from the host allocator supplied to their Context. Concurrent-marker, threaded-GIL, and parallel heaps retain std.heap.page_allocator; collector scratch remains outside the public heap budget. A focused identity/lifetime test locks down all three policy branches.

Order-balanced exact-parent screening used the frozen 1d76bfa0 / 4 MiB-nursery runner and 7 samples per row:

orderdirectwarmed 8 contextscold 8 contexts
baseline → candidate169.200 → 141.848 ms (-16.2%)478.795 → 453.792 ms (-5.2%)555.535 → 495.355 ms (-10.8%)
candidate → baseline127.126 vs 129.208 ms (-1.6%)407.758 vs 437.200 ms (-6.7%)443.483 vs 634.486 ms (-30.1%)

Checksums were exact in every run (1030552128 direct; 8309369344 at eight lanes). A 10-second candidate profile contained no mmap/munmap samples, versus 76 matching call-tree entries in the current-main profile. The focused allocator-policy test passed with no leak, and the complete quick comparison matrix passed all groups/checksums.

The clean seven-sample publication matrix and broader test gates are next; this issue remains open until those results and README/report updates land.

9 days ago

Completed in two pushed conventional commits:

  • ab7b08fb — perf(gc): use host scratch for private contexts (#119)
  • 88bd1b00 — docs(bench): publish private scratch results (#119)

The scoped A/B, allocator profile, full 1,540-sample matrix, README/report/raw publication, 768/768 normal tests, 767 TSan tests plus one expected skip, and 24-page docs build are all complete. Independent/shared object-churn gaps remain correctly open in #62/#97/#116.

Sign in to comment on this issue.