Re: [go-nuts] stack vs heap allocation

Showing 1-7 of 7 messages
Re: [go-nuts] stack vs heap allocation Adam Langley 11/11/09 5:49 PM
On Wed, Nov 11, 2009 at 5:45 PM, inspector_jouve <kaush...@gmail.com> wrote:
> Documentation states that it's perfectly legal to return a pointer to
> local variable. I can't make sense of this statement. Does it mean
> that local variables are not allocated on stack?

Local variable allocation is up to the compiler. Obviously most local
variables can be allocated on the stack, but the compiler will make
sure that they are heap allocated if they need to be. (And taking the
address will trigger a heap allocation in 6g I believe, although 6g
might get smarter about this in the future.)

> What is the structure of stack then?

The stacks are heap-allocated and non-contiguous in memory. Each
function has a prelude that checks that there is enough stack space
remaining and allocates more if need be.

> Another issue is array allocation. Is array allocated on stack?

It might be. See above.

AGL

unk...@googlegroups.com 11/11/09 5:45 PM <This message has been deleted.>
unk...@googlegroups.com 11/11/09 6:02 PM <This message has been deleted.>
Re: [go-nuts] Re: stack vs heap allocation Nigel Tao 11/11/09 6:20 PM
2009/11/12 inspector_jouve <kaush...@gmail.com>:
> Compiler cannot know this. Struct allocated on stack may have pointers
> to other structures allocated on stack.

I think that the current, simple-but-it-works heuristic is that if you
ever have a pointer to something, the compiler ensures that the thing
pointed to is from the heap, not the stack. This may get tighter in
the future, with escape analysis.

Re: [go-nuts] Re: stack vs heap allocation Ian Lance Taylor 11/11/09 9:02 PM
inspector_jouve <kaush...@gmail.com> writes:

> Compiler cannot know this. Struct allocated on stack may have pointers
> to other structures allocated on stack. This issue can be resolved
> only
> dynamically, with the help of garbage collector. Effectively, this
> means there's no stack allocation in a usual sense. By usual sense I
> mean that upon return from function, stack pointer
> just gets adjusted, and all pointers to local variables automatically
> become illegal.
> The problem with your response ("up to compiler") is that I cannot
> imagine ANY kind of compiler, under ANY reasonable assumptions, to be
> consistent with these statements while
> preserving a regular notion of stack. Could you please describe a
> model of stack (just as example, to illustrate the idea)

The compiler can know this.  The compiler knows whether you ever take
the address of a variable.

In the simplest case: if you take the address of a variable, it is
always stored on the heap.  If you don't save a copy of its address,
the garbage collector will get it.  But if you don't take the address
of a variable, then it can be stored in the stack frame as for C/C++.

It's not hard to do better than that in some cases, but the general
rule is valid and reliable.

Ian


> On Nov 11, 8:49 pm, Adam Langley <a...@golang.org> wrote:
unk...@googlegroups.com 11/12/09 5:36 AM <This message has been deleted.>
Re: stack vs heap allocation Dan 11/12/09 1:48 PM
> Suppose you pass a struct to a function f as a parameter by value.
> Function f can take the address of this struct and store it somewhere. Your
> logic suggests that struct should be allocated
> in a heap. However, caller does not know anything about it - he passes
> struct in a stack!

The compiler can make a copy of the struct on the heap at the
beginning of the function.
You passed the parameter by value, so you can't expect the pointer to
point to your external struct object. Even if the compiler wouldn't
copy it to the heap, you have already made another copy on the stack
before calling the function!