WebAssembly memory64/GC: upstream corpora, host matrix, and terminal evidence

Parent: #267 Depends on: #296, #297, #298, #299 Related: #268, #147, #305, #366 Roadmap: #142, #134

Publish the auditable completion gate for Memory64 and Wasm GC.

Acceptance:

• Extend the exact-pin corpus runner and inventory schema for every declared Memory64/GC file, command, execution mode, host, and architecture with zero hidden filtering.
• Publish per-file and aggregate pass/fail/not-applicable/runner-error totals with explicit reasons.
• Add bounded pin/drift/behavior CI witnesses and deliberate complete-run commands.
• Pass host-limit, deep/cyclic graph, precise-GC, lifecycle, failure, leak, stress, and sanitizer gates across supported hosts.
• Document JavaScript/system-engine comparison boundaries, architecture limits, reproduction, and committed performance evidence in README and WebAssembly docs.

Completion evidence:

• Memory64: 13,826/13,826 applicable across 23 files, 92 explicit text-only N/A, zero fail/runner
• GC: 697/697 applicable across 18 files, one explicit malformed-text N/A, zero fail/runner
• Multi-memory dependency #305: 829/829, zero fail/N/A/runner
• Integrated exact Core 3: 63,964/63,964 applicable across all 258 files, including the complete Memory64 and GC suites
• Exact pins: WebAssembly/memory64@9003cd5e24e53b84cd9027ea3dd7ae57159a6db1, WebAssembly/gc@756060f5816c7e2159f4817fbdee76cf52f9c923, wasm-tools 1.253.0@c799bb87b9cf9dc4fa7d11d63c5d52cbb3c4eb38
• Full sanitizer/stress/lifecycle matrix: CI run 29697559754
• Dedicated Core3/Memory64/GC publication job: success in run 29740530109
• Ten-profile terminal inventory/matrix publication: aa70d874

First terminal-evidence checkpoint is on main in 1c368e8.

The live command-level corpus driver now declares the exact 23-file Memory64 and 18-file GC selections, pins their proposal and WABT revisions, enables the matching evaluator feature profiles, and emits separate schema-v2 runtime inventories. Memory64 module-definition directives are preserved as compile-only commands instead of being accidentally instantiated.

Focused runner evidence:

• address64.wast: 242/242 passed;
• float_memory64.wast + memory64.wast: 159/159 passed;
• runner structural tests: 8/8 passed.

The pinned WABT 1.0.39 converter exposes Memory64 but does not implement GC text parsing despite advertising the GC feature flag. GC therefore remains an explicit conversion runner error, not a hidden skip. The next checkpoint is a pinned proposal-reference binary conversion path, followed by the full per-file matrices.

Terminal runner scalability checkpoint pushed in 21d251e.

The driver now shards only at independent module epochs, keeps each module with its dependent actions/assertions, preserves original command ordering in the merged inventory, rejects unsafe registration-dependent sharding, and records the shard count. The original 120-second watchdog stays unchanged.

Result: memory_copy.wast moved from 8,900 timeout records to 8,900/8,900 pass with zero failures, N/A, or runner errors. Runner structural tests are 9/9 green.

The first complete 23-file attempt also made the two remaining boundaries explicit:

• imports.wast contains ambient multi-memory coverage. That separately scoped missing profile is now #305 rather than being hidden or mislabeled as Memory64.
• table.wast uses typed-reference text that pinned WABT 1.0.39 does not parse; it shares the proposal-reference conversion work already required for the GC files.

I am keeping the checked-in terminal inventory pending until those boundaries have truthful command-level classifications.

Pinned the terminal GC profile to wasm-tools 1.253.0 at source commit c799bb87b9cf9dc4fa7d11d63c5d52cbb3c4eb38 and pushed the reproducible converter integration in 8148d5d3.

Current exact-corpus baseline at proposal revision 756060f5816c7e2159f4817fbdee76cf52f9c923:

• 375 / 698 assertions pass
• 322 semantic failures
• 1 non-applicable malformed-text case
• 0 converter or runner errors

The converter/harness layer is therefore no longer hiding corpus coverage. The dominant engine gap exposed by the failures is GC extended constant expressions (ref.i31, struct.new*, and array.new* in global initializers), which causes module-compilation failures and downstream registration cascades. I am implementing that next before publishing the durable terminal score and README table.

Pushed the next terminal-evidence milestone:

• c1d01eb9 — GC extended constant expressions, aggregate/i31 globals, typed-table initializers, correct nullable-i31 traps, and eqref scoring
• a6feef68 — canonical 18-file inventory plus the current README/docs score
• exact result: 542 / 698 pass, 155 semantic failures, 1 malformed-text N/A, 0 runner errors
• improvement over the converter baseline: 375 → 542 passes and 322 → 155 failures
• focused gates: 12/12 native Wasm GC tests, 9/9 runner tests, 46/46 array.wast, 73/73 i31.wast, zero leaks

The README is now 729 words (down from 1,009 in the prior condensed version) while retaining the current zig-js single/multithread vs JSC, SIMD, and Threads benchmark tables.

The acceptance boxes remain open because this issue is the combined GC + Memory64 terminal gate. Next implementation work is selected from the committed failure inventory: array segment/defaultability cascades, cast-branch/control typing, reference tests, and subtype/link compatibility; Memory64 multi-memory is separately tracked by #305.

GC terminal checkpoint (ff6004db):

• pinned corpus: WebAssembly/gc@756060f5816c7e2159f4817fbdee76cf52f9c923
• converter: wasm-tools 1.253.0 at c799bb87b9cf9dc4fa7d11d63c5d52cbb3c4eb38
• evaluator engine: e60432ab
• result: 697 / 697 applicable, 0 failures, 1 malformed-text N/A, 0 runner errors across all 18 declared files / 698 commands
• focused terminal clusters: cast branches 74/74, reference tests 71/71, subtype validation/runtime/linking 106/106
• lightweight publication checks: feature registry 4 profiles / 12 features; runner tests 9/9

The canonical inventory is committed at docs/.data/wasm-gc-runtime-inventory.json; README and docs/wasm.md now publish the same score. This completes the GC half of #300. The issue remains open because it is the combined Memory64/GC terminal gate; complete Memory64 inventory/typed-table evidence and the independently tracked multi-memory dependency (#305) remain.

CI heads-up from the ABI side: run 29673142405 on 062ef265 (current tip of main) is broadly red — unit shards 0/1/3, tsan-unit 0/1/3, tsan-nogil-corpus 0/1, wasm-core-2-structural-smoke, wasm-simd-smoke, threadfuzz-midgc all completed/failure (shard 2/4 green across suites). No CI run has completed green in several days; every recent run was cancelled by push concurrency, so the exact commit that introduced this is unobserved.

Attribution evidence for the parts I own: the ABI slice in 062ef265/e56f5843 (#308, URL parse-layer allocator-first refactor + 13 additive c_api exports) was validated by worktree A/B against pinned base 939dae44 — full zig build test on both sides, byte-identical failure sets (only the three known pre-existing gc/wasm.decode/wasm.validate failures). I additionally reproduced zig build test -Dunit-shard-index=1 -Dunit-shard-count=4 locally (macOS Debug) on the exact 062ef265 tree: 289 passed, 0 failed, 0 leaked — so the CI unit (1/4) failure is not reproducible from my change on this platform. The breadth (wasm smokes + tsan + threadfuzz across three shards) also points at shared/wasm-side state rather than a surgical URL regression.

Logs are 403 from here, so I can't name the failing CI tests. If the next completed run stays red, worth bisecting the unvalidated window 939dae44..54f183fc on a Linux runner — that range landed without a single completed CI run.

CI attribution — run 29676155824 on bcf9b0fd is broadly red, not from the URL/docs slices. Failed jobs: wasm-simd-smoke, wasm-core-2-structural-smoke, unit shards 0/1/2, tsan-unit 0/1/2, tsan-nogil-corpus 0/2, threadfuzz-midgc. Green: wasm-mvp-smoke, wasm-feature-profiles, test262-parallel, all threads-*, most threadfuzz-*, docs.

The run covers 632e8c50 (SIMD integer kernels → native vectors) plus the #309 URL exports and docs. Local evidence isolating the URL/docs side: a clean worktree A/B at base bcf9b0fd (which includes 632e8c50) with the #312 URL__originLength candidate on top ran all four unit shards at 1152 passed / 3 failed with an identical baseline-vs-candidate failure set (only the three known pre-existing: gc slab size, wasm.decode malformed, wasm.validate GC canonical recursive type identity) — and the same base at #309 showed the same result. The breadth of the CI failures (simd smoke + unit/tsan/corpus shards) instead points at the SIMD native-vector lowering under CI's target — same signature as the earlier 939dae44..54f183fc window. Leaving this here as the attribution record; no action on the Home/Bun ABI track.

Final CI/host-evidence slice is on main in 9226876a: the Memory64/GC job builds the evaluator, checks out both exact proposal commits, verifies the official wasm-tools 1.253.0 archive digest, and executes 391 representative terminal commands (Memory64 address/table64 plus GC aggregate/i31/cast control). The complete GC reproduction command is now documented. Awaiting descendant matrix https://github.com/zig-utils/zig-js/actions/runs/29708347319 before checking the remaining acceptance boxes.

Completed. Both exact proposal profiles and the integrated Core 3 corpus are terminal green; host/architecture constraints, complete-run commands, bounded exact-pin CI, and sanitizer/stress/lifecycle evidence are published.