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

254 views
Skip to first unread message

Lars Hansen

unread,
Sep 15, 2021, 8:10:59 AM9/15/21
to dev-pl...@mozilla.org
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.



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

unread,
Sep 15, 2021, 2:07:45 PM9/15/21
to Lars Hansen, dev-pl...@mozilla.org
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

unread,
Sep 16, 2021, 2:10:53 AM9/16/21
to Tom Ritter, dev-pl...@mozilla.org
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
Reply all
Reply to author
Forward
0 new messages