Skip to content

Perf: queue allocation-metadata lock handoffs #30

Description

@chrisbbreuer

Downstream zig-js #97 still spends the dominant shared-realm object-churn worker time waiting for Heap.alloc_lock while batches publish or the collector sweeps. The current TTAS + bounded-yield policy fixed repeated failing CAS writes (#26), but a fresh 10-second eight-lane profile at zig-js daf74724 / zig-gc 092d8d7 still recorded 14,619 scheduler-yield top stacks and 1,908 allocObjectBatch top stacks. Every waiter polls the shared lock word and periodically yields; short publication sections and the longer sweep tail share the same handoff path.

Scope

  • Prototype a fair queued allocation-metadata lock whose waiters spin on private/local state and hand ownership directly to the next waiter.
  • Preserve the uncontended fast path, the single-mutator lock-free path, all-list/counter/born-cell ordering, and collector exclusion.
  • Avoid heap allocation, TLS lifetime hazards, reentrancy, or abandoned stack-node references in the lock implementation.
  • Reject the design if it regresses one/two lanes or fails to materially improve both four and eight lanes in an order-balanced exact-parent downstream A/B.

Acceptance

  • Prove mutual exclusion and exact lock acquisition accounting in zig-gc tests.
  • Pass the full zig-gc heap suite and focused downstream allocation/GC/no-GIL tests, including TSan.
  • Improve downstream shared object churn at four and eight lanes with exact checksums and no one/two-lane regression.
  • Publish only the winning general implementation; document and fully revert a losing prototype.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions