ReviewOS

zig-utils/zig-js

GC: test Promise against its production slab slot

#1030
Closed chris opened this 10 days ago ·
10 days ago

Follow-up to #1026.

Problem

Current main 8794ccc5 fails the unit test gc.test.Promise fits the 256-byte GC slab:

expected 256, found 248

Promise is correctly packed to a 216-byte payload. With zig-gc's 32-byte header, Heap.cellAllocationBytes(Promise) is the exact 248-byte request. Production GcCellBacking rounds that request into its 256-byte size class, so the runtime optimization is present; the test incorrectly equates the unrounded request with the selected slab slot.

Exact unmodified-main reproduction:

zig test --dep regex --dep gc -Mroot=src/gc.zig \
  -Mregex=../zig-regex/src/root.zig -Mgc=../zig-gc/src/root.zig -lc \
  --test-filter 'Promise fits the 256-byte GC slab'

Scope

  • Expose the production GC backing's selected slab-slot size for a requested cell size.
  • Assert that Promise's exact request stays within budget and selects the 256-byte production slot.
  • Keep the payload packed; do not add padding merely to make the raw request equal the bucket size.
  • Run the focused GC invariant and backing size-class tests.

No-workaround rule

Do not weaken the 256-byte production size-class invariant or add wasted payload padding. Test the allocator decision the invariant actually describes.

10 days ago

Resolved on main by 549c58c0.

The production allocator was already selecting the 256-byte slab: Promise has a 216-byte payload, zig-gc requests 248 bytes including its header, and GcCellBacking rounds that request to its 256-byte slot. The failed test compared the unrounded request with the rounded slot.

The fix exposes the production slab-slot selection, keeps the compact payload, and asserts both the raw budget and exact production size class.

Evidence:

  • exact unmodified-main reproduction: expected 256, found 248
  • focused Promise fits the 256-byte GC slab: 1/1 passed
  • GC cell backing bucket stats attribute size-class pressure: 1/1 passed
  • no runtime behavior change

Sign in to comment on this issue.