Spec+runtime tracking issue

[SebastienGllmt]

Tracking issue for features we need from the following:

Wasmtime

• Run Pulley in the browser to generate a trace from WAT
  • Missing async fiber implementation
  • Debug tracing (used for proving) also seems to rely on fiber implementation
  • Can Wasm async be done without platform fibers?
• Serializing Wasmtime component state (call stacks not necessary - mainly linear memory and globals). Note: may be possible with wizer
• Implement the WebAssembly GC Proposal bytecodealliance/wasmtime#5032
• (low priority) Opcode rewriting standard (low priority as we can do it from our side). Prior art: rWasm
• (low priority) Save WASM state and resume bytecodealliance/wasmtime#3017 (can build our own instead of generic support)
• (low priority) API to access custom sections bytecodealliance/wasmtime#10218
• (maybe feasible as-is) opcode granularity for trace debugging learn more

Component Model

• Pre-Proposal: Wasm GC Support in the Canonical ABI WebAssembly/component-model#525
• Async, specifically for the exception to the component reentrancy ban
• Preferred way to extend / attach extended metadata to WIT (special comments? custom binary section?). See wac for prior art
• Interaction with the memory64 proposal WebAssembly/component-model#22 (low priority: 32-bit is enough for smaller proofs)
• (maybe not required) Add runtime instantiation to component model WebAssembly/component-model#423 / First-class modules WebAssembly/component-model#523

Wasm itself

• (low priority) Stack switching
  • wasmtime: Tracking issue: Stack switching proposal implementation status bytecodealliance/wasmtime#10248))

Other tools

• In-browser wRPC
• wasip3
  • WASIp3, threading ABI changes, LLVM releases, and schedules WebAssembly/wasi-sdk#589 (wasip3 release)
  • jco support (seems to work in practice now, but no official 100% support)