This is about safe allocation of stack frames. One limit to the size of a stack frame is the size of the address space. Safe compiled code should not use the low 32 bits of a calculated frame size to ask for more stack space. Here is an economical way to answer the more frequent question concerning availability of stack space in the prelude of a routine. We suppose that the kernel can invalidate one page of addresses at the end of the space for each stack in an address space. It may suffice to make such a page read-only, if that is easier. A routine’s prelude presumably stores into a newly allocated frame. If the stack frame size is known at compile time to be less than a the size of a page then there is no chance that a frame allocation will skip over the invalid page at the end of stack space. When the compiler cannot be sure that the new frame is less than the size of a page then it can spend extra instructions in the prelude to ask if there is space. But how does the compiled code know the end of the stack space? This is the interesting question of thread local storage. Thread local storage could hold that limit but how is that storage found? When several threads share all or nearly all of an address space then where is the limit found against which the stack pointer is compared to detect stack overflow? How does the compiled code know the end of its stack space? This would seem to require one of: The Wikipedia article describes several API's for this but does not say how they are implemented.

With a bit of coordination with memory trap logic, a civilized report can be made of exhaustion of stack space.

Early PL/I compilers for the 370 allocated such a register for thread specific information and used a “segmented stack”. Every call would test if there was still room in the current stack segment and allocate another segment if necessary. A stub frame was provided in the segment upon such allocation, return to which would deallocate that segment.