Native C-like programming environments tend to divide memory into several regions:
- static data contains predefined constants loaded from the binary, and space for global variables (“data”)
- your actual code has to go in memory too! (“text”)
- space for dynamic memory allocation (“heap”), which may grow “up” as more memory is needed
- space for temporary data and return addresses for function calls (“stack”), which may grow “down” as more memory is needed
Usually this is laid out with the stack high in the address space and the heap lower in the address space, if I recall correctly? Allocating more heap is done when you need it via malloc, and the stack can either grow or warn of an overflow by using the CPU’s memory manager to detect use of data pages incremented beyond the edge of the stack.
In emscripten’s WebAssembly porting environment, things are similar but a little different:
- code doesn’t live in linear memory, so functions don’t have memory addresses
- because code return addresses and small local variables also live separately, only arrays/structs and vars with address taken must be on stack.
- usable memory is continguous; you can’t have a sparse address space where stack and heap can both grow.
As a result, the stack is fixed size and there’s some fragility, but the stack uses less space usually.
Currently the memory layout is to start with static data, follow with the stack, and then the heap. The stack grows “down”, meaning when you reach the end of the stack you end up in static data territory and can overwrite global variables. This leads to weird, hard to detect errors.
When making debug builds with assertions there are some “cookie” checks to ensure that some specific locations at the edge of the stack have not been overwritten at various times, but this doesn’t always catch things if you only overwrote the beginning of a buffer in static data and not the part that had the cookie. :) It also doesn’t seem to trigger on library workflows where you’re not running through the emscripten HTML5/SDL/WebGL runtime.
There’s currently a PR open to reduce the default stack size from 5 MiB to 0.5 MiB, which reduces the amount of memory needed for small modules significantly, and we’re chatting a bit about detecting errors in the case that codebases have regressions…
One thing that’s come up is the possibility of moving the stack to before static data, so you’d have: stack, static data, heap.
This has two consequences:
- any memory access beyond the stack end will wrap around 0 into unallocated memory at the top of the address space, causing an immediate trap — this is done by the memory manager for free, with no false positives or negatives
- literal references to addresses in static data will be larger numbers, thus may take more bytes to encode in the binary (variable-length encoding is used in WebAssembly for constants)
Probably the safety and debugging win would be a bigger benefit than the size savings, though potentially that could be a win for size-conscience optimizations when not debugging.