bytecodealliance / bytecodealliance/wasmtime

Implement support in the component model for memory64

Open
#4,311 1 comment 0 reactions 0 assignees View on GitHub
wasm-proposal:component-model wasm-proposal:memory64
Dominant language
Rust
Stars
18.6k
Forks
1.8k
Avg merge
1d 18h
Merged PRs (30d)
126

Description

I'm going to split this work item from https://github.com/bytecodealliance/wasmtime/issues/4185 since I suspect it's going to be somewhat significant. The intention here is to track issues related to the memory64 proposal for WebAssembly and the component model. At the time of this writing neither of these proposals are "stable". Additionally the component model does not actually define what the canonical ABI is with respect to the memory64 proposal. Fully implementing this item will be a blend of "do the obvious thing" where possible such as making pointers 64-bits large, while at the same time also identifying question that don't have "obvious" answers such as "what's the maximum length of a string or list?"

Currently there are a lot of TODO items sprinkled throughout `typed.rs` which note various places that I suspect will need memory64 treatment. Fully implementing this issue, however, will likely require fuzzer integration because otherwise it'll be difficult to ensure that we've covered all cases.

Some examples of things that need updating are:

* Need to call `realloc` with a different signature
* All reads/writes of pointers to linear memory need to have a 32/64 bit switch
* Reading and writing pointers to `ValRaw` needs to be audited
* Size and alignment calculations all need to be duplicated or have a parameter for 64 bit
* Somehow should probably confirm that this doesn't vastly affect performance for 32-bit

The last point here is an open question I don't know how best to answer.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.