memory-control

> But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead asmjs is going to be strictly more limited in interacting with JS than wasm. You're basically limited to simple number values and array buffers. Whereas wasm now a days has GC types and can hold onto JS value using externref. > But more important for what i was trying to do, you can't zero copy buffers from js to wasm I'm pretty sure you can't do that with asmjs either. There is a proposal for zero-copy buffers with wasm: https://github.com/WebAssembly/memory-control/blob/main/prop...

I'm pretty sure this is just "yes (parts of), memory control in WASM works"[1]. The whole Apple Silicon thing is (in this case) just added details that don't actually matter. [1] https://github.com/WebAssembly/memory-control/blob/main/prop...

The “single array of memory” is not the problem; that’s what all these languages already expect. The problem is the lack of meaningful memory APIs, e.g. virtual memory capabilities. I am co-champion of a proposal to fix this but have not been able to prioritize it for a while, unfortunately: https://github.com/WebAssembly/memory-control/blob/main/prop...

Does this allow for shrinking the WebAssembly.Memory object? - https://github.com/WebAssembly/design/issues/1397 - https://github.com/WebAssembly/memory-control/issues/6 This is a crucial issue, as the released memory is still allocated by the browser.

Indeed, webassembly is moving extremely slowly. I started a project years ago expecting https://github.com/WebAssembly/memory-control/blob/main/prop... and https://github.com/WebAssembly/memory64 to be fixed at some point. Neither are yet, and the project still suffers from it to this day. I think wasm is still great without these fixes, but I have lost confidence in the idea that wasm will reach its full potential any time soon.

Additionally, googlers are championing memory control https://github.com/WebAssembly/memory-control/blob/main/prop..., which provides memory protection, as well as memory 64, which is already done in chrome and firefox https://github.com/WebAssembly/memory64/blob/main/proposals/...

No having an unmapped zero-page by default is a result of Web Platform integration. There isn't an easy interop story with JS ArrayBuffer where there are inaccessible holes. And it's not just JS (and therefore a JSVM issue); a lot of code in the web platform (e.g. Chromium) uses the memory of ArrayBuffers rawly and is not prepared to encounter holes (OS-level signals). That said, we are working on this: https://github.com/WebAssembly/memory-control

FWIW there is a proposal in the works to add page-based protection, which will allow unmapping the 0 page, restoring the trap-on-null-deref behavior that is important for many languages with safety checks. https://github.com/WebAssembly/memory-control

WASM is not designed to work around the shortcomings of C. The fact that nowadays the program crashes with a segmentation fault error after a null pointer dereference is only because modern operating systems are being nice to you. But a proper error handling can still be implemented into WASM. Maybe, the following proposal on memory control will add the option: https://github.com/WebAssembly/memory-control/blob/master/pr...