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 On Wed, Sep 15, 2021 at 8:07 PM Tom Ritter <[email protected]> wrote: > 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 > > On Wed, Sep 15, 2021 at 12:10 PM Lars Hansen <[email protected]> wrote: > > > > 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 > > > > -- > > You received this message because you are subscribed to the Google > Groups "[email protected]" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > 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 > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAHOPy%3Do8Egh8ZT3c3kJBbba3U13rubPUXgu8vFP2N%3DpG2ymffw%40mail.gmail.com.
