ReviewOS

zig-utils/zig-js

GC: register and trace live precise sibling realms

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

Parent: #415 GC parent: #144 Roadmap: #134

Introduce the heap-owned registry that makes every live precise sibling realm an explicit root source.

Acceptance:

  • Give each precise heap one immutable owner and a synchronized live-realm registry.
  • Register siblings only after complete bootstrap and retire them only after execution/jobs/threads quiesce.
  • Trace and relocate every registered realm root exactly once per collection.
  • Keep standalone precise contexts and arena C context groups unchanged.
  • Add focused add/trace/relocate/retire ordering and TSan evidence.
9 days ago

Foundation pushed to main in 63a62c1c:

  • embeds one immutable owner plus synchronized sibling list beside the precise heap/binding/backing allocation
  • routes heap root tracing and relocation through the owner and every registered sibling
  • preserves the standalone owner-only path
  • focused lifecycle allocation test passes 3/3 with zero leaks

This intentionally does not check off #420 yet: sibling bootstrap registration, quiescent retirement, and an actual cross-realm trace/relocation witness remain.

9 days ago

Second engine-core slice pushed in bddba479:

  • adds registerBootstrapped, retireQuiescent, foreign-heap/owner/duplicate rejection, and synchronized registry counts
  • marks the registry lock trace-sensitive because the collector reacquires it
  • retirement now synchronizes active-interpreter/thread state and rejects pending task, property-waiter, microtask, nextTick, rejection, timer, finalization-cleanup, and async-waiter work
  • exact-once owner+sibling root tracing and relocation are exercised before and after retirement
  • four sibling records concurrently register and retire against one precise owner
  • focused Debug, ReleaseSafe, and TSan all pass 4/4 with zero leaks

#420 remains open: a production sibling cannot safely allocate into this heap until #421 records per-cell realm ownership. After #421, the real shared-precise bootstrap will call these operations rather than the test-only modeled attachment.

9 days ago

Follow-on #421 commit c3cfb00 now gives the heap owner and every registered sibling a stable realm ID, and records that identity in cell-backing side metadata. This removes the ownership ambiguity that blocked real shared-precise bootstrap. #420 remains open until the production sibling creation path is wired to allocate/bootstrap on the shared heap and register only after complete initialization.

9 days ago

138d203 completes the realm-aware collector/callback substrate needed by production shared-precise bootstrap: active Context state now carries both heap and stable realm, cells/side stores attribute to that realm, and retiring realms remain callback-addressable until all owned cells drain. The remaining #420 work is now the production sibling constructor plus C-API group entry wiring and failure-atomic bootstrap/registration—not GC ownership ambiguity.

9 days ago

Bootstrap lifecycle checkpoint 54d3c19 is on main.

The heap registry now distinguishes:

  • owner/live siblings: traced roots and eligible allocation-recovery realms,
  • bootstrapping siblings: stable ID + callback routing, but deliberately excluded from roots and allocation recovery,
  • retiring siblings: excluded from roots but retained for cell/finalizer routing until drain.

beginBootstrap reserves identity before the first precise cell; registerBootstrapped atomically promotes the completed realm; releaseFailedBootstrap refuses while attributed cells remain. Debug registry tests cover promotion, recovery refusal for a partial realm, and failure release; 4/4 pass with zero leaks.

This isolates the next production C-API constructor work from the teardown work in #419. README/benchmark data remains unchanged because this is lifecycle correctness, not a new benchmark run.

9 days ago

Completed by 63a62c1, bddba47, c3cfb00, 138d203, and 54d3c19. All acceptance items are checked; arena C context groups remain intentionally unchanged for #416.

Sign in to comment on this issue.