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/CADua4_vRWmxMeSXo1%3Dgzs2n5NdopuXNFUEfQQNXvSwqYhmOeqw%40mail.gmail.com.
