Yet another strike against the current AA implementation

[Andrei Alexandrescu]

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."

> 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.

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
$ _

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.


Andrei