Rust updates

[David Piepgrass]

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.