Re: [go-nuts] stack vs heap allocation

3,876 views
Skip to first unread message
Message has been deleted

Adam Langley

unread,
Nov 11, 2009, 8:49:52 PM11/11/09
to inspector_jouve, golang-nuts
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

Message has been deleted

Nigel Tao

unread,
Nov 11, 2009, 9:20:12 PM11/11/09
to golang-nuts
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.

Ian Lance Taylor

unread,
Nov 12, 2009, 12:02:54 AM11/12/09
to inspector_jouve, golang-nuts
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:
Message has been deleted

Dan

unread,
Nov 12, 2009, 4:48:53 PM11/12/09
to golang-nuts
> 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!
Reply all
Reply to author
Forward
0 new messages