Intent to prototype: WebAssembly 64-bit memory model ("memory64")

[Lars Hansen]

Summary: Pointers into wasm linear memory are currently represented in wasm programs as 32-bit unsigned integers.  This has two consequences considered negative by developers: heap sizes are limited to 4GB (when computers have much more physical RAM than that), and C/C++/Rust code bases that target wasm must be compatible with a 32-bit pointer size (when native deployment almost always can assume a 64-bit pointer). The memory64 proposal removes these restrictions by allowing heaps to be larger than 4GB and to be addressed using 64-bit integers.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1677586

Standard (evolving): https://github.com/WebAssembly/memory64.

Spec stability and issues: The spec is stable and appears uncontroversial.  However, the cost of bounds-checking 64-bit accesses remains a concern (and of course memory consumption will increase with 64-bit pointers).  Adopters of 64-bit pointers may find that there's still no such thing as a free lunch.

Security & privacy: There might be some generalized concern about how allocating very large memories can be used to reduce the efficacy of ASLR.  Wasm memories will be capped at the max size set by the JS engine, currently 8GB.  Any increase of that limit for JS+Wasm will only be after discussions that take that concern into account, and so the memory64 work does not bring any new concerns to the table in that regard.

Platform coverage: All (including also 32-bit platforms, to simplify deployment to the web)

Preference: javascript.options.wasm_memory64, eventually.

Devtools bug: None at this time.

Other browsers:

Chrome: is prototyping this and leading the spec work

Safari: I'm aware of no signals

Web-platform-tests: To appear

[Tom Ritter]

There are a lot of various memory safety (or perhaps more correctly)
'memory-unsafety-mitigation' proposals that steal bits from pointers
to create memory tags or what-have-you. Given that we're only
effectively going from 4 -> 8 GB for web-accessible code (and that we
could in theory modify any <whatever> -> wasm compilation in the
future) - I'm assuming that there's nothing in this that would
preclude or significantly hamper our ability to use those in the
future, but I wanted to double check.

-tom

> --
> You received this message because you are subscribed to the Google Groups "dev-pl...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dev-platform...@mozilla.org.
> To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAHOPy%3Dr2usN4AHhhBC6GgcNXfoQzT88W_5akS4hGWgViSPw_kA%40mail.gmail.com.

[Lars Hansen]

We will almost certainly go beyond 8GB in the not distant future, once we're sure that things are working out OK.  But apart from compatibility pressure from the other browsers as to how large heaps we allow, nothing in the proposal should preclude limits on the heap sizes, excluding certain address ranges in virtual memory, and so on.

--lars