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.

"Christopher Wright" <dhasenan@gmail.com> wrote in message news:gh759s$2ucs$1@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)?

Nick Sabalausky wrote:
> "Christopher Wright" <dhasenan@gmail.com> wrote in message news:gh759s$2ucs$1@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)? 

If you required a physically contiguous stack that could be logically noncontiguous, yes. You need a logically contiguous stack that does not need to be physically contiguous, though, so that fails. You'd have to change pointers.

Christopher Wright wrote:
> 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.

	Actually, on Linux, the stack for the main thread grows dynamically
until it reaches the allowed size. It is *not* allocated with the
full size at the start. For other threads OTOH, the stack is
allocated once and for all at thread creation.

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeberger@free.fr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeberger@jabber.fr   |
+---------------------------------+------------------------------+

Jérôme M. Berger wrote:
> 	Actually, on Linux, the stack for the main thread grows dynamically
> until it reaches the allowed size.

That's exactly what I said. It didn't occur to me beforehand that you could preallocate the stack, but now that I think about it, nobody would be happy if Linux preallocated 8MB for every process.

Thanks for the information on threads, though.