On Wednesday, 11 July 2012 at 18:31:23 UTC, David Piepgrass wrote:
The trouble with segmented stacks are:
1. they have a significant runtime penalty
Why?
Extra instructions generated for each function.
Every function? Why?
Looks like I misunderstood what "Segmented stacks" are. From an
LLVM page:
Segmented stack allows stack space to be allocated
incrementally than as a monolithic chunk (of some worst case
size) at thread initialization. This is done by allocating
stack blocks (henceforth called stacklets) and linking them
into a doubly linked list. The function prologue is responsible
for checking if the current stacklet has enough space for the
function to execute; and if not, call into the libgcc runtime
to allocate more stack space. Support for segmented stacks on
x86 / Linux is currently being worked on.
I envision a rather different implementation for 32-bit code.
1. Reserve a normal stack with one 4K page committed + some known
minimum amount of uncommitted memory, e.g. another 8 KB
uncommitted with a guard page that the program can trap via OS
facilities (signals, etc.)
2. When the stack overflows, move the stack to a new, much larger
region of Virtual Memory. Much like languages that support
compacting garbage collectors, the language / runtime environment
must be designed to support this.
3. If one needs to call C code, one preallocates the maximum
expected virtual memory needed, e.g. 32 MB.
