277743 2024-08-07 10:05:28 -0700 [WASM] Add support for multi-memory proposal 2026-03-24 11:02:17 -0700 1 1 1 Unclassified WebKit WebAssembly WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 285505 1 d_degazio d_degazio anand_srinivasan chi187 cryze92 github jensaxel luka webkit-bug-importer oldest_to_newest 2051161 0 d_degazio 2024-08-07 10:05:28 -0700 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. 2051162 1 webkit-bug-importer 2024-08-07 10:05:45 -0700 <rdar://problem/133394285> 2073442 2 chi187 2024-11-07 01:22:30 -0800 The proposal has been shipped in Firefox 120 (21/11/2023) and Chrome 125 (11/05/2024) 2120927 3 github 2025-05-31 11:54:30 -0700 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/ 2126597 4 jensaxel 2025-06-29 11:47:08 -0700 Any news? 2126966 5 luka 2025-07-01 04:34:23 -0700 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) 2179560 6 ews-feeder 2026-02-09 13:41:14 -0800 Committed 307103@main (bdf26416947e): <https://commits.webkit.org/307103@main> Reviewed commits have been landed. Closing PR #56967 and removing active labels. 2187162 7 anand_srinivasan 2026-03-04 16:39:20 -0800 <rdar://problem/171755537> 2193177 8 ews-feeder 2026-03-24 11:02:17 -0700 Committed 309850@main (4ac3b92ed23f): <https://commits.webkit.org/309850@main> Reviewed commits have been landed. Closing PR #58817 and removing active labels.