WebAssembly profiles: memory64 and GC

[chrisbbreuer]

Parent: #142
Depends on: #262
Related: #144, #145
Roadmap: #134

Implement pinned memory64 and Wasm GC profiles without conflating them with the engine's host GC roadmap.

Acceptance:

• Pin exact memory64 and Wasm GC revisions, dependencies, and test inventories.
• Implement 64-bit memory addressing/growth with overflow-safe host limits and deterministic unsupported-host errors.
• Implement selected Wasm GC types, validation, allocation, casts, instructions, and JS/reference boundaries.
• Integrate Wasm references with precise tracing, weak behavior, teardown, and future moving-GC rewriting.
• Publish upstream totals, stress/leak evidence, and host constraints.

Child issue map

• WebAssembly memory64: pinned corpus, binary IR, and validation #296 — memory64 proposal inventory, binary IR, and validation
• WebAssembly memory64: execution, JavaScript API, and host limits #297 — memory64 execution, JavaScript API, and host limits
• WebAssembly GC: pinned corpus, recursive types, and validation #298 — Wasm GC proposal inventory, recursive types, and validation
  • Wasm GC: make the canonical recursive identity witness spec-correct #318 — spec-correct canonical recursive identity witness (landed; awaiting Linux CI)
• WebAssembly GC: runtime objects, casts, and precise tracing #299 — Wasm GC runtime objects, casts, identity, and precise tracing
• WebAssembly memory64/GC: upstream corpora, host matrix, and terminal evidence #300 — complete upstream corpora, CI, host matrix, and terminal evidence

Implementation order

#296 precedes #297, while #298 precedes #299. The memory64 and GC tracks may proceed independently after their inventories are pinned. #300 closes only after both tracks are implemented and every declared upstream command has an explicit result and execution mode.

[chrisbbreuer]

Decomposed into #296-#300 before implementation. I am starting with #296, the memory64 pin/binary/validation boundary; the independent Wasm GC inventory begins at #298, and #300 owns the combined no-hidden-filter completion evidence.

[chrisbbreuer]

#296 is complete and closed: the exact memory64 binary/type/validation boundary, drift verifier, malformed diagnostics, allocation-failure rollback witness, README, and docs are on main. Continuing with #297 for runtime execution, public JS API/BigInt semantics, and host limits.

[chrisbbreuer]

GC terminal child checkpoint: the pinned GC runtime inventory now scores 697 / 697 applicable, with zero semantic failures, one malformed-text N/A, and zero runner errors across all 18 files / 698 commands. Publication landed in ff6004d and the detailed evidence is on #300.

#267 remains open: #300 is deliberately still open as the combined Memory64/GC evidence gate, with the complete Memory64 inventory/typed-table boundary and multi-memory dependency #305 remaining. The parent acceptance item and #300 child box therefore stay unchecked.

[chrisbbreuer]

Multi-memory is now independently terminal under #305: 829/829 commands pass across all 38 declared proposal files with zero failures, skips, or runner errors. The gate, indexed runtime paths, registry pin, inventory, and concise README/docs update are pushed through c2d6d61b. The parent remains open for #300's complete Memory64 terminal inventory and final supported-host evidence.

[chrisbbreuer]

Memory64 proposal semantics are now terminal under #300: 13,826/13,826 applicable commands pass across all 23 declared files / 13,918 commands, with 92 explicit text-only N/A and zero semantic or runner failures. Together with GC at 697/697 applicable and multi-memory at 829/829, the remaining parent boundary is the final supported-host/architecture matrix and green publication CI witness.

[chrisbbreuer]

Completed through #300. Memory64 and Wasm GC have exact green terminal inventories, precise reference/GC integration, deterministic host limits, bounded CI, full sanitizer/stress evidence, and documented host constraints.