Tail call elimination

[Nick Sabalausky]

"Christopher Wright" <dhasenan at gmail.com> wrote in message 
news:gh759s$2ucs$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> On a side note, stack overflows are still possible anyway (whether 
>> functional or imperative). Is there a reason (other than inertia) that 
>> stack frames aren't set up like a dynamic array to grow as needed? (Of 
>> course, I can understand not doing that during a debug build to help 
>> detect unintentional infinite recursion) I realize the overhead of 
>> checking the stack size on every function call might be undesirable, but 
>> (not that I've given this much thought) is there no trick to set 
>> something up to automatically trigger when the stack fills up? Or, isn't 
>> it already detecting stack overflow anyway (I know some languages do 
>> that)? (Of course, I'm not saying any of this would be a substitute for 
>> TCE, just a good compliment to it.)
>
> You allocate memory whenever you overflow the currently allocated stack. 
> The caveat is that it has to be contiguous to the existing stack 
> (virtually contiguous, not physically contiguous). In the best case, as 
> soon as you allocate something outside the stack, you've set a limit on 
> the stack size.
>
> On Linux, if your stack exceeds its allowed size, you get SIGSEGV. You can 
> trap this, but you need to specify an alternate stack to do so. On my 
> machine, the default stack limit is 8MB, though you can change that. I 
> assume that setting the limit will alter the ranges that heap memory 
> allocation can deal with, as well.

I see, so a relocatable stack would be required, and I can see how that 
would be a problem. Is it (at least in theory) possible to use paging tricks 
to transparently move the stack to a location with more available space 
(perhaps with the cooperation of both the OS and the GC)?