3 ms·

Giving you a buffer that grows is the allocation approach I am talking about. This is not how your OS works. Your OS itself works with an allocator that does a

Giving you a buffer that grows is the allocation approach I am talking about. This is not how your OS works. Your OS itself works with an allocator that does a pretty good job making sure that your memory ends up not fragmented. Because WASM is in between, the OS is not in control of the memory, and instead the browser is. The browser implementation of "bring your own allocator" is cute but realistically just a waste of time for everybody who wants to deploy a wasm app because whatever allocator you bring is crippled by the overarching allocator of the browser messing everything up. It seems like the vendors are recognizing this though, with firefox now having a discard function aparently! https://github.com/WebAssembly/design/issues/1397 https://github.com/WebAssembly/design/issues/1397

sph 4y ago
> This is not how your OS works. Your OS itself works with an allocator This is exactly how your OS works. There is no malloc syscall. You call sbrk [1] (the modern mechanism to do that on Linux eludes me, maybe it's through mmap), get a chunk of memory and do your thing. malloc is implemented in glibc, and you can swap it out with any other allocator, but your kernel just gives you a chunk of memory and it is your job (as userland process) to suballocate it, deal with fragmentation, etc. 1: https://en.wikipedia.org/wiki/Sbrk https://en.wikipedia.org/wiki/Sbrk
- vouwfietsman 4y ago
  I am not sure you read the link I posted. Picking a single point out of it, like "No way to shrink the allocated Wasm Memory." makes it clear that this allocation strategy is really very different to how your OS works when you call malloc/free outside of wasm. Also take a look at "Some applications need address space, not memory" in that link, same stuff. Long story short, running inside WASM is like running without virtual memory. Virtual memory was invented to solve a bunch of issues, so now WASM has all those issues unsolved.

sph 4y ago

> This is not how your OS works. Your OS itself works with an allocator This is exactly how your OS works. There is no malloc syscall. You call sbrk [1] (the modern mechanism to do that on Linux eludes me, maybe it's through mmap), get a chunk of memory and do your thing. malloc is implemented in glibc, and you can swap it out with any other allocator, but your kernel just gives you a chunk of memory and it is your job (as userland process) to suballocate it, deal with fragmentation, etc. 1: https://en.wikipedia.org/wiki/Sbrk https://en.wikipedia.org/wiki/Sbrk

vouwfietsman 4y ago
I am not sure you read the link I posted. Picking a single point out of it, like "No way to shrink the allocated Wasm Memory." makes it clear that this allocation strategy is really very different to how your OS works when you call malloc/free outside of wasm. Also take a look at "Some applications need address space, not memory" in that link, same stuff. Long story short, running inside WASM is like running without virtual memory. Virtual memory was invented to solve a bunch of issues, so now WASM has all those issues unsolved.