Skip to content

Runtime: define heap cap and per-thread OOM contract #24

Description

@chrisbbreuer

Child tracker from #11/#16/#1.

Goal

Define and maintain the public heap-cap and per-thread OOM contract for zig-js contexts, including how allocation pressure is surfaced to hosts and to shared-realm Thread joiners.

Current status

The original PR-249 blocker semantics/oom-one-thread.js is now promoted. GC-backed capped contexts can collect and retry at safe GC cell allocation failures and ArrayBuffer byte allocation failures, and the reference recovery witness passes.

Implemented contract:

  • Context.Options.heap_limit_bytes applies a thread-safe outstanding-byte budget to Context-owned allocator traffic.
  • Context.heapBudgetStats() reports limit, used, peak, and remaining bytes for capped contexts.
  • Top-level host evaluation reports unrecovered cap pressure as Zig error.OutOfMemory.
  • A capped context prebuilds an immutable OutOfMemoryError object so shared-realm Thread completion can publish a deterministic JS error value even when ordinary heap allocation is exhausted.
  • join() rethrows that reserved object, and already-created asyncJoin() reactions reject with it when they can be delivered.
  • Allocation-site OOM can become catchable by active JS handlers in the covered interpreter/tree-walker paths, including catch-binding pressure that has pre-reserved environment storage.
  • Arena-backed caps remain fail-closed and non-reclaimable unless callers opt into GC-backed recovery.
  • GC-backed capped contexts can recover after unreachable pressure is collected at safe allocation-recovery points.

Remaining linked work

  • Runtime: extend heap-cap emergency recovery beyond current safe allocation classes #30 tracks the remaining emergency-recovery perfection work: no-GIL root-publication recovery, side-store pressure, and avoiding lock-order deadlocks during collect/retry.
  • Keep documenting any new capped allocation classes as either fail-closed, catchable, or recoverable.
  • Keep the PR-249 audit/probe evidence current if a future behavior change affects heap-cap cases.

Acceptance criteria

  • Heap-cap behavior is documented for arena-backed and GC-backed contexts.
  • Allocation failure remains observable as ordinary JS/host errors without corrupting GC state.
  • One capped shared-realm Thread can hit OOM while siblings and cleanup/finalization remain well-defined.
  • Promoted reference coverage and focused unit tests prove the intended supported contract.
  • Remaining uncovered allocation classes are tracked by narrower follow-up issues rather than hidden behind this parent tracker.

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

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions