Yet another strike against the current AA implementation

[Georg Wrede]

Andrei Alexandrescu wrote:
> Georg Wrede wrote:
>> Andrei Alexandrescu wrote:
>>> Computing the stack depth even for non-recursive functions is an 
>>> interprocedural analysis so it's difficult to do modularly. The stack 
>>> is also unchecked so going with a "good enough" approximation is 
>>> bound to be risky.
>>
>> The old size estimation problem. No matter how big you decide on, 
>> somewhere is an idiot who will blow that size too.
>>
>>
>> A runtime solution just occurred to me. The newly allocated stack for 
>> a thread is zeroed first, right? Well then, just before the thread 
>> finishes, one could scan the stack area, and find the first address 
>> that contains a non-zero value.
>>
>> This isn't bullet proof in theory, but hey, the aim is to help in 
>> /estimating/ the needed stack size.
> 
> You can't be more serious than Mark Twain when giving advice on the 
> stock market: "Buy some stock. If it goes up, sell it. If it doesn't go 
> up, don't buy it."

I'd be amazed if the stack usage of hello.d varied from run to run.

>> Incidentally, this raises another thought: what if the stack was 
>> extendable? Like D arrays? A stack overflow would trigger a relocation 
>> of the stack, and then continue. Being able to have hundreds of small 
>> stacks would be useful in other things than threads, too.
> 
> That would be great. I don't know whether it can be done.

Two methods come to mind.(1)

> By the way, I think you're underestimating how much stack the OS gives 
> to the stack. On my system:
> 
> $ grep PTHREAD_STACK /usr/include/**/*.h
> /usr/include/bits/local_lim.h:#define PTHREAD_STACK_MIN 16384
> /usr/include/pthread.h:   minimal size of the block must be 
> PTHREAD_STACK_MIN.*/
> /usr/include/pthread.h:   to be started.  This size must never be less 
> than PTHREAD_STACK_MIN

Seems like that minimum means the OS won't start a new thread with less 
[stack] space left on the computer. Gotta be /some/ value, big enough to 
be fine with virtually any app.

> You can't have a stack smaller than 16KB as far as I understand. I seem 
> to recall the default stack size is much bigger.

Totally not having researched this... The page 
http://www.unix.com/high-level-programming/34632-how-find-out-stack-size-occupied-process.html
states that "Most Linux systems have no stack limits set" (didn't have 
time to find a definitive reference, yet).

Also, PTHREAD_STACK_MIN would be the main process stack size. If we're 
running co-operative multitasking, or continuations or some such, then 
the other stacks really can be smaller.

The important thing to know is, does "somebody else" than our program 
use the current stack? If not, then we're free to allocate "just enough" 
(in practice much more) to the stacks. IIUC, our stack is only used by 
our app, its library calls, and the OS API calls.


(1) Using several stacks:

What does one need to use several stacks? Let's assume we have the 
"regular" stack, and then we temporarily want to use another.

First we allocate space for the new stack. Then we disable interrupts, 
(we could even save processor state), change the stack pointer to point 
to the new stack. Enable interrupts, and go on with the program (i.e. 
call the routine we want to have using the new stack). Once it finishes, 
disable interrupts, reset the stack pointer, enable interrupts.

Knowing in advance the needed stack space helps here. Especially if 
instances of the same code are to run with each stack, then all we need 
is an array of stack spaces. :-)

The other thing: suppose we really don't know the stack usage. Then each 
routine can use the same stack while it runs, and at task switch we copy 
the actually used portion of the stack to the heap. Next time we want to 
run that task, we copy the data back from the heap.

I admit this isn't done in an evening, but it's doable.