Generic and fundamental language design issue

Dmitry Olshansky dmitry.olsh at gmail.com
Sun Nov 4 10:14:32 PST 2012


11/4/2012 9:35 PM, Tommi пишет:
> I have a fundamental language design talking point for you. It's not
> specific to D. I claim that, most of the time, a programmer cannot, and
> shouldn't have to, make the decision of whether to allocate on stack or
> heap.

Actually it can and most definitely should. It's scoped lifetime vs 
infinite lifetime, reference and value semantics. And e.g. RAII structs 
have to be on stack to have their effect applied usefully. Storing the 
reference to 't' elsewhere implies heap allocation (be it GC heap or 
manually managed one).

Going further allocation strategy is a deep topic with a lot of 
considerations and in the end it goes far beyond stack vs GC heap.

> For example:
>
> void func(T)()
> {
>      auto t = <allocate T from heap or stack?>
>      ...
> }
>
> The question of whether variable t should lay in heap or stack, depends
> not only on the sizeof(T), but also on the context in which func is
> called at. If func is called at a context in which allocating T on stack
> would cause a stack overflow, then t should be allocated from the heap.

In fact placing big object on stack just because it fits could introduce 
stack overflow few hundred calls later.
In general compiler can't know beforehand how big stack space you'll 
need and thusly the portion of it to use safely.

> On the other hand, if func is called at a context where T still fits
> nicely on the stack, it would probably be better and faster to allocate
> t on stack.

Unless you escape references. Compiler could detect it but will stay on 
the conservative side. In the end it may end up with unexpected heap 
allocations.

>
> So, the question of whether to allocate that variable t on stack or heap
> is something that only the compiler (or runtime) can answer.

God no. It may as well depend on the code compiler knows nothing about 
(nor run-time for this matter).

extern(C):
int blah(void* ptr);

void func(T)()
{
       auto t = <allocate T from heap or stack?>
       blah(&t); //now what?
       ...
}

If blah doesn't store pointer somewhere inside you are fine with stack. 
If it does then not even GC heap will help you.

> Is there
> any language where you have the ability to say "allocate T from wherever
> it's best"?

In simplest case I'd consider ability to bypass allocation on heap as an 
optimization.

> I wonder if it would be possible in D to let the compiler allocate
> dynamic arrays on stack when it can statically guarantee that it's safe
> to do so (no dangling references, never increasing the size of the
> array, etc).


-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list