If I remember correctly, I think one of the downsides to WASM is that you can't reserve memory, and memory is limited to 16 GB, which the browser allocates up front. So I think WASM can't do this approach, unfortunately. Ben Visness talks about this in his Wookash episode and is something that is holding back WASM
In the original version of WebAssembly, the browser essentially reserves 4GB up front (or 16GB with wasm64) and you can commit 64KB pages by using the grow instruction. You have no real control of virtual memory beyond linearly committing pages in one 4-16GB region of memory. You can't have multiple linear memory allocators that you push/pop to independently.
However, I think this has changed recently with the multi-memory proposal:
Excellent article! Thank you!
If I remember correctly, I think one of the downsides to WASM is that you can't reserve memory, and memory is limited to 16 GB, which the browser allocates up front. So I think WASM can't do this approach, unfortunately. Ben Visness talks about this in his Wookash episode and is something that is holding back WASM
In the original version of WebAssembly, the browser essentially reserves 4GB up front (or 16GB with wasm64) and you can commit 64KB pages by using the grow instruction. You have no real control of virtual memory beyond linearly committing pages in one 4-16GB region of memory. You can't have multiple linear memory allocators that you push/pop to independently.
However, I think this has changed recently with the multi-memory proposal:
https://developer.mozilla.org/en-US/docs/WebAssembly/Guides/Understanding_the_text_format#multiple_memories
It doesn't give you full control of virtual memory, but you can linearly commit pages in multiple regions from the same WebAssembly module.