ReviewOS

zig-utils/zig-js

Perf: add a compact GC slab class for ordinary objects

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

Parent: #62 Related collector work: zig-utils/zig-gc#8

Problem

The current Object payload is 624 bytes (0x270 in the optimized allocation path). With the collector header it falls into GcCellBacking's 1,024-byte size class, leaving roughly one third of every hot slot unused. Object allocation churn therefore touches and indexes substantially more slab address space than the live cell requires, while the current profile attributes the remaining named costs primarily to nursery sweep/free, object creation, and slab allocation.

Scope

  • add a general intermediate cell size class that fits the current ordinary-object allocation exactly with safe 16-byte alignment;
  • choose chunk geometry that improves usable density without excessive empty-context reservation or metadata growth;
  • keep ownership classification, stale/interior-pointer rejection, free-list reuse, trimming, bulk teardown, parallel locks, and bucket statistics exact;
  • add focused tests for allocation, reuse, classification, and trimming in the new class;
  • measure clean pinned downstream object_churn A/B with exact checksum equality;
  • retain only a measured win; do not special-case benchmark source, function names, or object shapes.

Acceptance criteria

  • Object cells no longer consume 1,024-byte slab slots.
  • The new slot and chunk geometry has bounded fragmentation and empty-context reservation.
  • Fresh/reused/freed/live counters and ownership classification remain exact.
  • Wild, stale, interior, and delegated pointers retain current behavior.
  • Parallel allocation/free and tail trimming remain correct.
  • Focused semantic/GC tests pass.
  • Clean pinned object_churn A/B shows a repeatable improvement with checksum 1030552128.
  • The commit references this issue and evidence is added to #62.
9 days ago

Rejected after the required clean measurement; no source change was retained and no commit was made.

Evidence:

  • optimized Object payload: 624 bytes; collector allocation total fits the proposed 768-byte class;
  • focused ownership/reuse test passed 2/2;
  • GC profile moved the 1,047 bootstrap cells from 1,024-byte slots to 768-byte slots while retaining three backing chunks;
  • order-balanced pinned A/B, 12 fresh warmed processes per binary, 100 object_churn jobs each:
    • current main baseline median: 615.516 ms
    • 768-byte class median: 654.894 ms
    • regression: 6.40%
    • exact checksum: 1030552128 in every run.

The denser class likely loses because it changes the favorable 1,024-byte alignment/address pattern without reducing the 624-byte payload initialization or number of swept cells. Future work should reduce the Object payload itself or remove dispatch/allocation work, not add this intermediate slab class.

Sign in to comment on this issue.