On 11/4/2012 9:35 AM, Tommi wrote:
> 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. 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.

You can't determine this, even at runtime, because you don't know what subsequent calls will use enough stack to overflow it.

It is true, though, that you can do what is called "escape analysis", which if it can prove that a reference to the object cannot escape the function scope, then it can be allocated on the stack (if it isn't larger than some arbitrarily chosen size).

Such escape analysis is entirely possible with D without changing any semantics.

On 11/4/2012 1:27 PM, Walter Bright wrote:
> Such escape analysis is entirely possible with D without changing any semantics.

The compiler already does a fairly primitive form of this analysis when deciding to allocate a closure on the stack or the heap.

On Sunday, 4 November 2012 at 21:27:36 UTC, Walter Bright wrote:
> You can't determine this, even at runtime, because you don't know what subsequent calls will use enough stack to overflow it.

Right, I didn't take into account that heap allocations use some stack anyway to store the pointers.

Since it's not possible to completely stop the stack from filling any further once it's been filled up, some kind of conservative heuristic should be used then for determining whether things should go on heap or not. That heuristic would be based on both compile-time and run-time analysis of the program. The heuristic cannot guarantee that there won't be a stack overflow, but neither can the programmer.

It's great that optimizations could be used to eliminate unnecessary heap allocations. But it could be interesting to imagine a language where it was impossible for the programmer to explicitly specify the allocation method. Things would go to heap if it was determined necessary by compile-time analysis, and also when the heuristics determine there might a danger of stack overflow. Otherwise things would go to stack. Pointers (or rather re-directable references) would always be used for referring to existing variables (that could be on heap or not). Pointers would never represent "a variable allocated on heap".

On 11/4/2012 3:20 PM, Tommi wrote:
> It's great that optimizations could be used to eliminate unnecessary heap
> allocations. But it could be interesting to imagine a language where it was
> impossible for the programmer to explicitly specify the allocation method.
> Things would go to heap if it was determined necessary by compile-time analysis,
> and also when the heuristics determine there might a danger of stack overflow.
> Otherwise things would go to stack. Pointers (or rather re-directable
> references) would always be used for referring to existing variables (that could
> be on heap or not). Pointers would never represent "a variable allocated on heap".

That's what Java does today.

Le 04/11/2012 18:41, Andrei Alexandrescu a écrit :
> On 11/4/12 12:35 PM, Tommi wrote:
>> 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.
>
> I don't think that claim is valid. As a simple example, polymorphism
> requires indirection (due to variations in size of the dynamic type
> compared to the static type) and indirection is strongly correlated with
> dynamic allocation. Also, the value vs. reference semantics of type are
> strongly correlated with where objects should go. So on the contrary,
> quite often heap vs. stack allocation is forced by the nature of what's
> allocated.
>

If it is proven that the object is scoped, then allocating it on stack make sens as well, even if it will be used only by reference.

On 2012-11-05 01:09, deadalnix wrote:

> If it is proven that the object is scoped, then allocating it on stack
> make sens as well, even if it will be used only by reference.

Exactly, I do that sometimes with "scope", but that is deprecated these days.

-- 
/Jacob Carlborg

Le 04/11/2012 18:35, Tommi a écrit :
> 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. 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.
> 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.
>
> So, the question of whether to allocate that variable t on stack or heap
> is something that only the compiler (or runtime) can answer. Is there
> any language where you have the ability to say "allocate T from wherever
> it's best"?
>
> 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).

BTW, Why can't we allocate 1Gb stack or something insanely big on 64bits systems ?

It will not use actual physical memory unless it is used, and much more stuffs can be allocated on stack.