ReviewOS

zig-utils/zig-js

GC: finish parallel collections in mid-GC condition and ThreadLocal witnesses

#812
Closed chris opened this 11 days ago ·
11 days ago

Parent: #476. Related: #502 and #792 (distinct failure signature).

Linux CI on f2340f2 failed the non-TSan threadfuzz-midgc gate: https://github.com/zig-utils/zig-js/actions/runs/33137549779/job/98740893155

Command: THREADFUZZ_SEED_TIMEOUT_MS=300000 zig build threadfuzz -Dfuzz-midgc=true -Dfuzz-iters=20.

Exact functional failures:

  • seed 8: midgc Atomics.Condition.wait did not finish a parallel collection
  • seed 12: ThreadLocal lifecycle did not finish a parallel collection
  • seed 17: midgc Atomics.Condition.wait did not finish a parallel collection

Final denominator: 900 programs from seed 1, 3 failures, wall-ms 931851. This is a failed collection-completion witness, not a reported sanitizer race, crash, or the condition completion-score assertion in #792. Root cause and introducing revision have not been established; do not label it a regression from parameter lowering without a before/after reproduction.

Reproduce the named seeds, inspect attempted/completed/aborted collection and peer-publication/parking evidence, and correct ownership or progress at the responsible boundary. Preserve the existing assertion and work budget: no added sleeps, relaxed denominator, forced extra drain, suppressed/disabled GC, or weakened collection requirement. Coordinate any native wait/job/lifecycle change with the actor owning that work. Verify normal and unsuppressed TSan mid-GC gates plus the full no-GIL integration checks.

11 days ago

Environment confirmed from the completed job log: ubuntu-24.04 x64, Zig 0.17.0-dev.1818+7051f8e. Local macOS builds use 0.17.0-dev.1441_d5181a9, so a passing local seed alone would not establish Linux parity. The complete failed-job log is retained in /Users/chris/.cache/zig-js-proxy.Hdh6eC/prior-ci-midgc-job.log.

11 days ago

Current-main verification on bcc3e757 clears the issue-specific mid-GC failures without changing either named witness or its work budget:

  • Linux normal mid-GC gate: job 99584763501, 900 programs from seed 1, 0 failures, 1,046,003 ms
  • Linux unsuppressed TSan mid-GC gate: job 99584763574, 90 programs from seed 1, 0 failures, 741,440 ms, no TSan report
  • local exact focused repros: Atomics.Condition.wait seeds 8 and 17 each 1/1; ThreadLocal lifecycle seed 12 1/1
  • local full per-seed profiles: seeds 8, 12, and 17 each 45/45

For attribution discipline, I also built the parent of d05d274c in an isolated detached worktree and ran the unchanged 900-program profile. It passed 900/900 locally on macOS, so that run does not reproduce the Linux defect and does not establish d05d274c as the unique causal fix. The original Linux 3/900 evidence remains valid; current Linux parity is now green.

The broader no-GIL integration run exposed different signatures, now tracked separately:

  • #836: api/lock-async-hold.js and api/condition-async-wait.js exhaust the 600-second Debug and ReleaseSafe corpus deadlines
  • #837: jit/spawned-thread-butterfly-stress.js throws TypeError: undefined is not an object in Debug and ReleaseSafe

Neither is a failed parallel-collection completion assertion, and both normal/TSan mid-GC gates pass. Keeping #812 open until those acceptance-blocking integration regressions are fixed and the full no-GIL checks are green.

11 days ago

The two integration blockers linked above are now addressed by 14278310 — fix(threads): separate host task quiescence from child completion (#836, #837).

Local committed-tree integration is now green:

  • no-GIL corpus: 253/253 Debug and 253/253 ReleaseSafe
  • normal mid-GC threadfuzz: 900/900
  • unsuppressed TSan mid-GC threadfuzz: 90/90
  • full units: 2,228 passed, 1 skipped, 0 failed/leaked

The task-lifecycle fix is ownership-based: only the realm host waits for peer in-flight task quiescence, while spawned Threads publish completion without a cyclic dependency on a host task that may be joining them. Reentrant task bursts remain linked as exact moving-GC roots. No #812 collection assertion, work budget, GC mode, or corpus baseline was changed.

Keeping #812 open until the exact Linux push run confirms the normal/TSan mid-GC and no-GIL integration gates: https://github.com/zig-utils/zig-js/actions/runs/33440235057.

11 days ago

The required Linux confirmation is now complete on current main in run 33463092639:

  • normal mid-GC threadfuzz: 900/900, success
  • unsuppressed TSan mid-GC threadfuzz: 90/90, success
  • Debug no-GIL corpus: all four shards successful
  • ReleaseSafe no-GIL corpus: all four shards successful
  • TSan no-GIL corpus: all four shards successful
  • unit and TSan-unit matrices: all eight shards successful

The original failed collection-completion witnesses, their work budgets, and their assertions remain intact. The run has failures in unrelated lifecycle, GIL-corpus, Wasm-profile, inventory, and benchmark-harness jobs; none reports the #812 mid-GC completion signature, and they will remain separately tracked.

Closing #812 as completed based on the repeated Linux normal/TSan mid-GC evidence and the now-green full no-GIL integration matrices.

Sign in to comment on this issue.