Bug 277743
| Summary: | [WASM] Add support for multi-memory proposal | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | David Degazio <d_degazio> |
| Component: | WebAssembly | Assignee: | David Degazio <d_degazio> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | chi187, cryze92, github, jensaxel, luka, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 285505 | ||
| Bug Blocks: | |||
David Degazio
The multiple memories proposal for WASM has been fully standardized (phase 5) per https://github.com/WebAssembly/proposals, and is currently in the process of being merged into the spec. Beyond the fact we lack support for this feature, this also means we can't easily pull in newer versions of the spec tests without disabling some assertions. We should re-enable these checks once support for multiple memories is added to WebKit.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/133394285>
Sergey Rubanov
The proposal has been shipped in Firefox 120 (21/11/2023) and Chrome 125 (11/05/2024)
github
Are there any status updates on this? Looking at the Feature Status tracker[1] indicates that multiple memories support in Safari is essentially the only major blemish when it comes to browser compatibility in Stage 5 that can't just be "compiled around" (like lack of support for relaxed SIMD) or simply isn't relevant to browsers.
On a more personal level, this is a pain-point for languages targeting the browser that are looking at using WASM threads, which is Stage 4 but widely supported and a major landmark feature for compiler devs, that don't want to share ALL of their memory among threads.
1: https://webassembly.org/features/
jensaxel
Any news?
luka
Hi, I just wanted to add that supporting this feature would enable many important optimisations and useful patterns that would otherwise not be possible:
- In some cases, it would be possible to avoid JS-side memory copies by directly reading from/writing to a separate memory buffer in wasm
- It would enable having multiple large resizable buffers, which could simplify memory allocation logic and would avoid wasm memory heap fragmentation
- Having unshared memory when threading (as previously mentioned)
- Can be used to efficiently sandbox memory reads and writes in user-generated modules with an api that requires some main memory context (e.g. in plugins)
EWS
Committed 307103@main (bdf26416947e): <https://commits.webkit.org/307103@main>
Reviewed commits have been landed. Closing PR #56967 and removing active labels.