4 ms·
> 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 m
by 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 agoI 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.