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

[chrisbbreuer]

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 WebAssembly profile: multi-memory binary, runtime, and corpus #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

[chrisbbreuer]

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.

[chrisbbreuer]

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 WebAssembly profile: multi-memory binary, runtime, and corpus #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.

[chrisbbreuer]

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.

[chrisbbreuer]

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.