Here's an example with a bit of explanation: if you pass a value to fmt.Println it will escape. The raw println builtin does not cause values to escape. So calling the first function twice and seeing the same address for the value strongly implies stack allocation while calling the 2nd function twice and getting different addresses implies heap allocation.
Thank you for explaining what's going on there! :)
And btw, compiling the above example with -gcflags="-m" (which I learned about earlier today) proves you right.
:= kinda smears the clarity by not allocating if you have a variable on the left that is already allocated, and there's some other places where it kinda smears things up, but at the core, Go makes you explicitly allocate.
Most people probably think "heap allocation" when you say this. Go doesn't do dynamic allocations within a stack frame (alloca in C), so when you say "it's an allocation", what does that mean? It could be a stack allocation that occurred at compile time as a reservation in the size of the stack frame for that function. It could be a heap allocation. Only the compiler knows!
The Go compiler is the ultimate authority on what becomes a heap allocation. It tries to make everything into a stack allocation when possible, and stack allocations are "free".
Beyond that, a sufficiently smart compiler can reuse stack "allocations" within a single function as certain values become "dead" (never used again). So there isn't even guaranteed to be a 1:1 correspondence between "stack allocations" and variables that you declared inside the function.
So, I completely disagree with your statement about Go being "relatively explicit about allocations." It's one of the least explicit compiled languages in that regard.
Go makes a distinction between declaration and assignment, which is the syntax you're talking about. It really has nothing to do with allocations.
Also, allocations are just... allocations. Go qua Go doesn't have stack vs. heap, and it's a mistake to care except when optimizing. So in Go qua Go, it isn't an issue that it may "reuse" a particular address, because in Go qua Go you can't witness that anyhow. (If you try to keep a pointer around to witness it with, you'll keep the thing pointed to alive.) From Go's perspective, it's still an allocation even if the implementation manages to re-use a particular memory address to do so.
I'm talking about the runtime Go implements here, not the implementation.
This actually took me some years to correctly internalize, for what it's worth. It does a "good" job of glossing over things. However, if you really poke at it, allocations are still explicit. They just may not look like what you are used to from other languages.
temp := someFunc()
p := &temp
p := &someFunc()
The simpler way to think about it is that in Golang everything is on the heap. However the optimizer will move things to the stack if they don't have their address taken. I think the point about explicitness is that if you don't use `&` then it will be able to be put on the stack. So `&` doesn't cause a heap allocation but lack of `&` (or new()) confirms that there isn't one. (I don't actually know if that is true but I can't think of any counterexamples)
I think assigning to a pointer would cause an escape.
Just taking a reference wouldn't though, the reference still has to escape (of course you'd usually take a reference so that it can escape but that's not always the case, especially with inlining).
*x = y x := make(map[int]int)
x[0] = 5
y := &x[0]
*y = 10
print(x[0]) // 5 or 10?
x[0] = 6
print(*y) // 6 or 10?
// force the map to grow and reallocate the buckets
for j := 1; j < 100; j++ {
x[j] = j
}
*y = 11
print(x[0]) // 5, 6, 10, or 11?
edit: changed the second print to *y instead of x[0]. thanks masklinn for catching this error.
Do you mean `print(*y)`? You just assigned to `x[0]` so its value should not be in question.
Also
> if it's the latter, resizing the map invalidates the pointer, so it must be updated somehow.
It doesn't (have to) invalidate the pointer though. When resized the map's content get copied to a new backing buffer, the pointer can keep pointing to the old buffer. That's basically the same behaviour as slices: when a slice resizes, a new backing array is allocated, the contents get copied to the new array, and the slice is retargeted to the new array. There can be other slices pointing to the old array (it's of course a very bad idea to update slices to shared arrays, but Go will let you do it).
That's true, but I don't think it's very comparable to slices. With slices, you have to explicitly reallocate either by creating a whole new slice or using append. Reslicing, indexing, or other operations do not reallocate. On the other hand, maps may end up resizing on any operation that involves them, or even theoretically in the background without any operations (during GC, for example). It would be unfortunate to lose that implementation flexibility, and keeping it means that you're essentially picking the "make a copy" option.
It's exactly the same.
> With slices, you have to explicitly reallocate either by creating a whole new slice or using append.
That's a distinction without a difference. `append` does not "explicitly reallocate", it may or may not reallocate, you've no idea. Even if the backing array is full, it might be realloc'd in-place.
> On the other hand, maps may end up resizing on any operation that involves them, or even theoretically in the background without any operations (during GC, for example).
So?
Also technically nothing prevents a GC from reallocating the slice.
> It would be unfortunate to lose that implementation flexibility, and keeping it means that you're essentially picking the "make a copy" option.
I've never heard of a hashmap implementation which would do otherwise.
Trying to extend in-place and attempting to properly redistribute if that works sounds like absolute hell. Likewise trying to shrink in-place, though at least you've got some scratch space which you don't have in the other case: you'd have to segregate everything into one half of the map then insert them in the other half, before shrinking your allocation, which might give you a new allocation anyway, at which point you've moved all your values thrice whereas just creating a new allocation and reinserting your stuff there is a single move.
Maybe to you, but to me, a pointer going from modifying the value inside of the map to no longer modifying the value inside of the map during any operation is quite a bit different than requiring a reassignment of the slice header. In other words:
x := make([]int, 5)
y := &x[0]
x[3] = 8
*y = 5
print(x[0]) // always prints 5
x := make(map[int]int)
y = &x[0] // btw, is this even valid? let's assume it implicitly does x[0] = 0
x[3] = 8
*y = 5
print(x[0]) // maybe sometimes prints 5?
> Also technically nothing prevents a GC from reallocating the slice.
It would have the same problem the map does: you'd have to update any pointers into the slice to point to the new slice, otherwise the semantics of the program changes. That is not something the GC currently does, and would require an awful lot of metadata and scanning.
> I've never heard of a hashmap implementation which would do otherwise.
I'm not sure what this is referring to. I agree every map implementation has to reallocate the backing store of values periodically. I was trying to say that keeping the flexibility to reallocate the backing store of the map during GC means that you cannot choose the "writes through pointer are observed in the map" option (at least without a lot of complication around updating pointers) because as a programmer, you would not be able to know if it would do that or not, which is a fairly useless primitive.
Yes, I avoid making assumptions about invariants across mutation calls, that's just a bad idea.
> For slices, we know that x[0] will always print 5 until the value of x is reassigned in some way.
Unless an other goroutine is stomping on your backing array anyway.
> It would have the same problem the map does: you'd have to update any pointers into the slice to point to the new slice, otherwise the semantics of the program changes. That is not something the GC currently does, and would require an awful lot of metadata and scanning.
Yes. So maybe we could ignore that useless strawman?
> I'm not sure what this is referring to.
To what I'm quoting.
> I was trying to say that keeping the flexibility to reallocate the backing store of the map during GC
That sounds less like flexibility and more like "let's make the GC slower and more complex for no reason".
> := [...] an error to use it when it doesn't allocate.
> := [...] not allocating if you have a variable on the left that is already allocated,
This appears to be a contradiction.
I suppose you mean something like "error to use it when there's no possible context where that line of code would allocate"; what's an example of that?
If either a or b (but not both) were already defined, this won't re-define (and reallocate space for) them.
foo := MyStruct{}I believe the person you are replying to was making a confusing point about some hand wavy notion of "any kind of allocation", which includes stack allocations... which are determined at compile time, not with "alloca".
foo := MyStruct{} // Could live on the stack
_ := &foo // Oh, now foo must live on the heap.No matter what syntax you write inside a function, the Go compiler always has the final say on what is stack allocated and what is heap allocated. Taking the address of foo will not cause foo to be heap allocated unless Go is unable to prove that the pointer will live for less time than the current stack frame. Look up "escape analysis".
Basically the only way to guarantee that something will always be heap allocated is to assign it to a global variable. Even returning a pointer to that object from the current function is not a strong guarantee, since the compiler could inline this function into the caller and determine that everything can live happily inside the newly inlined stack frame without heap allocation.
Otherwise the meaning of &f().x is different for f() returning pointer-to-struct and f() returning struct.
Similarly &m["x"] is a compile error today but would silently make a copy tomorrow rather than produce a pointer to the value in a map.
All of that would be incredibly confusing and the source of many subtle bugs.Offtopic: Surprisingly I was asking myself this question but if possible in C... Is it?
In C:
int *f() {
int x = 0;
return &x;
}
Note that C++ does somewhat allow this with lifetime extension. It is somewhat like what I expected Go to do, except because lifetime extension only extends to the enclosing block it is more of a footgun. With a dynamic tracing garbage collector like Go it not a footgun.
int* ref1() { return &1; }
-> error: lvalue required as unary '&' operand
//
#include <stdlib.h>
int alloc() {
return *(int*)malloc(sizeof(int));
}
int* ref() { return &alloc(); }
-> error: lvalue required as unary '&' operand
int* make_unsafe_ref() { int a; return &a; }
-> warning: function returns address of local variableI mean it could implicitly allocate, that's what Rust does for instance.
Your second and third attempts would not compile though, the first would by returning a `&'static T`.
Maybe. I just meant that storage is created implicitly (static or stackframe depending on the case), then a reference is created to that.,
&(T[]){ f() }
It seems odd that you can't apply & to a function's return value. I think the best approach would be making & work in basically any scenario. For example the following also doesn't currently work.
It seems like it should be possible to "desugar" &X to `_tmp = X; &_tmp` and solve this weirdness.