Threads: fix failing corpus cases mc-lock-stop-vs-park and oom-one-thread

[chrisbbreuer]

Parent: #478, #502
Related CI: `threads-gil`, `nogil-corpus-functional`

Problem

Two PR-249 thread corpus cases fail on Linux CI and keep otherwise-green gates red:

• `cve/mc-lock-stop-vs-park.js` — `Error: expected 400 but got 401` (observed in nogil-corpus-functional shard 1/4 on run 32589497696 and repeatedly in earlier runs referenced from Perf(shape): derive transition-map keys from one secure realm seed #662/Perf(object): publish initialized data descriptors atomically #663)
• `semantics/oom-one-thread.js` — `OutOfMemoryError: Context heap limit exceeded` (observed in threads-gil shard 3/4 of the same run)

These are engine behavior mismatches or overly strict case expectations, not sanitizer aborts. Until fixed (or the cases are corrected with evidence), the comprehensive gate boxes in #662 and #663 cannot close because every descendant matrix records these failures.

Required work

• Diagnose `mc-lock-stop-vs-park`: identify which lock/park/stop state machine transition produces 401 instead of 400; fix the engine or justify a case correcti

[chrisbbreuer]

Run 32592838252 narrows this issue: `cve/mc-lock-stop-vs-park.js` passed in the no-GIL functional gate this time (it failed in run 32589497696's shard), while `semantics/oom-one-thread.js` failed again in threads-gil shard 3/4. The stop-vs-park case looks flaky/order-dependent rather than deterministically broken; oom-one-thread remains deterministic.

[chrisbbreuer]

Diagnosed and fixed the deterministic half in bf069289 (`fix(gc): wait bounded for peer parks during heap-cap recovery (#722)`).

Root cause (`semantics/oom-one-thread.js`): allocation-failure recovery in GIL mode refused to collect unless every peer was already parked-and-published. Under sustained multi-thread allocation that predicate almost never held at the failing instant, so after the hog released its ~256MB hoard it hit a second OOM inside its one-retry tolerance window before any peer reached its next natural park — an uncaught `OutOfMemoryError`, exactly the CI failure. Recovery now waits bounded (50 ms) on the same all-parked safety predicate before refusing; peers park on their own via their existing Atomics.wait backoffs and GIL release, so no new handshake, lock, or shared state is introduced, and timeout preserves the old refusal exactly.

Evidence: 10/10 case passes in GIL mode and 5/5 in no-GIL mode locally; 46/46 heap-filtered un

[chrisbbreuer]

Second-stage diagnosis and fix in a2f30927 (`fix(gil): publish blocked acquirers so heap-cap recovery can collect (#722)`).

bf06928's bounded wait was necessary but not sufficient: `allOthersParked` requires every peer to be parked-and-published, yet a peer blocked on contended GIL `acquire()` blocks opaque in `lockUncancelable` with no published scan range. Once any peer queued on the lock — which is the steady state once the hog holds it — the predicate could never become true while recovery held the GIL, so recovery still refused and the case kept dying with the uncaught second OOM (run 32599447828, threads-gil shard 3/4, same 12 s signature). Contended `acquire()` now publishes the blocked stack exactly like `wait`/`yieldIfContended` already do: the blocked stack is stable and the conservative scan roots its temporaries, so a collector holding the GIL can safely includ

[chrisbbreuer]

Precise diagnosis from run 32606818819's runner diagnostics (threads-gil shard 3/4):

• `heap budget: used 201326495 / limit 201326592` — the heap is saturated to within 97 bytes of the cap at the moment of failure
• thread state: id=1 `threw=true`, all joins settled — consistent with the hog's post-release retry allocation, i.e. recovery ran but freed nothing

Conclusion: this is no longer a liveness/scheduling problem (both prior fixes stand — publication of blocked acquirers is independently correct). The hoard becomes garbage precisely, but the hog's own native stack retains stale word-copies of hoard-element pointers from the allocation storm, and the conservative scan therefore pins every element array as live. A full collection legitimately frees zero bytes, so the retry OOMs again and the second throw escapes. That also explains platform variance: whether stale slots survive depends on stack reuse, which differs between macOS an

[chrisbbreuer]

Fresh descendant-main reproduction in CI 32804870572, no-GIL functional shard 1/4: cve/mc-lock-stop-vs-park.js failed after 438 ms with expected 400, got 401; all six thread completion records were done=true exited=true threw=false joins-settled=true. The shard passed 62/63 cases. This run contains only unrelated Math/iterator-protocol changes after the previously known reproduction.