3 ms·
You give it a heap. It doesn't allocate memory. It may allocate within its own heap, using whatever allocator/gc strategy it inherits from it's host language.
by thrax 7y ago
You give it a heap. It doesn't allocate memory. It may allocate within its own heap, using whatever allocator/gc strategy it inherits from it's host language.
- kllrnohj 7y agoWhich means it can't free. But that's also not accurate, anyway, there's a brk() method to grow the heap. Which is such a bad starting point for a new runtime.
- saagarjha 7y agoWould it be impossible to implement mmap and sbrk in the runtime?
- kllrnohj 7y agommap is arguably the only thing it should have had in the first place. brk/sbrk is fairly dead.
- saagarjha 7y ago$ strace /bin/ls 2>&1 | grep brk brk(NULL) = 0x55fb032b3000 brk(NULL) = 0x55fb032b3000 brk(0x55fb032d4000) = 0x55fb032d4000
- wahern 7y ago$ ktrace /bin/ls >/dev/null $ kdump | grep brk | wc -l 0 $ kdump | grep mmap | wc -l 130 glibc, musl, and jemalloc got the memo, they just couldn't be bothered to stop using brk by default. They're all capable of using mmap exclusively, however, because whether or not brk is actually dead, there's long been consensus that mmap is the better abstraction on balance, particularly given the benefit of ASLR. So there's little reason to support brk instead of mmap for compatibility. Presumably it was chosen for the convenience of WebAssembly implementations--contiguous, flat memory is a great simplifier of VM, JIT, and even traditional AoT architectures.
- AnIdiotOnTheNet 7y agoRight, and while you can grow the heap you can't give any of it back, so you can't really dynamically contract your memory without restarting the process.