View mode: basic / threaded / horizontal-split · Log in · Help
November 04, 2012
Re: Generic and fundamental language design issue
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.
November 04, 2012
Re: Generic and fundamental language design issue
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.
November 04, 2012
Re: Generic and fundamental language design issue
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".
November 04, 2012
Re: Generic and fundamental language design issue
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.
November 05, 2012
Re: Generic and fundamental language design issue
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.
November 05, 2012
Re: Generic and fundamental language design issue
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
November 05, 2012
Re: Generic and fundamental language design issue
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.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home