Hacker News Reader

Comment by ernst_klim | Hacker News Reader

What? Are Go interfaces and strings stack allocated? If not, this assertion looks dubious to me.

Go uses escape analysis at compile time to determine where to allocate each variable. If the variable is shown to not 'escape' the current goroutine's stack, then it is can be allocated on the stack. Otherwise it is said that the value 'escapes' to the heap.

You can see what the escape analysis has determined for each variable by building like so: go build -gcflags "-m"

Unfortunately it can be hard to know by just looking at code if something will be stack or heap allocated. You can allocate a struct and take its pointer, and have it still end up on the stack, for instance (which is good). You can also have seemingly obvious flows for a variable that the analyzer can't reason about and it escapes when you didn't think it would. You really just have to run the tool to see if you want to be sure.

> You can also have seemingly obvious flows for a variable that the analyzer can't reason about and it escapes when you didn't think it would. You really just have to run the tool to see if you want to be sure.

And this is why "get programmers to manually optimize their code to please escape analysis" is not a reasonable memory management strategy.

Nobody is suggesting that. Go has very good profiling support, and that's how performance optimization starts.

If profiling finds that there are too many allocations on a hot path, you might want to see why they escape to heap. But that's a last resort strategy.

This sounds very much like "write code to please escape analysis", but with a profiling step in front of it.

No, there's a difference. Profiling will often show you where you're doing allocations or calling code that does allocations in the most often used code. Profiling shows where to reduce those allocations to get the biggest improvements. When making the changes, you don't try to reduce escapes, you reduce allocations.

Have a look at [1] and go down to where it says " To find out why the garbage collector is running so much".

[1] https://blog.golang.org/profiling-go-programs

I am not disagreeing with you but am confused on the issue. Java also has escape analysis, so I wonder what makes the difference here.

That is a good point. I don't know, so I've been googling around and came across this awesome article:

https://shipilev.net/jvm-anatomy-park/18-scalar-replacement/

It essentially says that java doesn't (ever?) allocate Objects on the stack, but it sometimes approximates it by just storing the scalar values (that would have been part of the object) on the stack, and never allocating the object (with its headers) at all. The end result is similar.

It also has a mention of an easy way to confuse the escape analysis (though Go's escape analysis has many pitfalls as well).

I'm speculating, but it could be partly that the escape analysis and resulting scalar replacement is a hotspot optimization, and therefore the Java GC has to be well tuned to handle non-jitted items. It may have something to do with what types of failure cases each of the languages have with their analysis.

The HotSpot JVM does indeed do escape analysis. The primary difference is that, in Go, you can put structs and arrays inside other structs.

I tend to be skeptical of the claims that are often made that Go data structures have different GC-relevant characteristics from those of Java, or especially C#.

Can you elaborate why being able to embed objects within another void this hypothesis?

Java used to default to heap allocation for pretty much everything, but added escape analysis as an optimization. For Go escape analysis as been part of it since day 1. Basically Java is heap by default that uses the stack when it can. Go uses the stack unless it determines it must use the heap.

Most go data is value types that can be assumed to be on the stack, unless you introduce a pointer explicitly or use one of the referenceish types like interface, string, array or map. Its very easy for both the programmer and the compiler to see when data escapes.

Java on the other hand is pathologically bad for escape analysis, outside of ints and floats literally every object in java is presumed to be on the heap. Even C# has less heap pressure than java typically because of more value type options, and not type erasing greatly improves the JIT's escape analysis. After sufficient JITing Java may reach go level of garbage generation, it may not: but its not deterministic.

That's garbled in several ways I'm afraid.

Firstly type erasure and escape analysis are un-related. Whether an object escapes or not is unrelated to things like whether it's a List<Integer> or List<int>.

Secondly .NET doesn't do escape analysis at all:

https://github.com/dotnet/coreclr/issues/1784

Thirdly HotSpot will happily escape analyze and then scalar replace regular objects, it isn't limited to ints and floats. It can make a big difference in many situations.

Fourthly and finally, if it were "easy to see where data escapes" in Go there wouldn't need to be tools to help the programmer find out, and Go developers wouldn't spend time manually tweaking to try and ensure the optimisation works.

Type erasure and escape analysis are not entirely unrelated. If you have an array of pairs and store a pair into that array then the pair is considered to escape in Java because you're actually storing a pointer to your original pair. In C# that array can store a true array of pairs rather than an array of pointers to pairs. A pair you store gets copied into the array, so the original pair does not have to be considered to escape and can be stored on the stack and deallocated when the function exits.

Although C# does not have escape analysis, its value type vs reference type distinction serves roughly the same purpose, but under manual control of the programmer.

Only if you are speaking about Hotspot.

GraalVM and other Java JITs (J9, Azul, PTG, ...) have much better escape analysis algorithms.

In Go you can pass and return by value. That's why it's far more effective in Go and of very limited applicability in Java. For instance if you're working with a pair of numbers and only use that pair locally in one function, then Java escape analysis works. If that pair was returned from another function or passed to another function then escape analysis fails in Java but still works in Go. In Go the escape analysis only fails if you explicitly make a pointer to that pair of numbers and pass that to another function.

Let me say that I am not super familiar with the Go source, and so this may be wrong. Please correct me if this is true!

My understanding is, the string itself is on the stack, but the data is on the heap https://github.com/golang/go/blob/2f2e8f9c81d899d8eefb1f2f98...

Likewise, the "double pointer" of an interface is on the stack, but points to the heap: https://research.swtch.com/interfaces

So, from a lifetime perspective, it's still pretty stack-like. If you make a string, and you don't refer to it from outside the function, it's gonna get noticed by escape analysis and be like anything else on the stack.

>the string itself is on the stack, but the data is on the heap

So both are regular heap allocated values? So the majority of data is still stack (edit: heap) allocated (safe ints, floats and some simple structs, I suppose), so I fail to see how ``young objects live and die young on the stack''.

It is true that some GCed languages does not have stack allocation at all, but many of them (java, haskell) have very powerful inlining capabilities to compensate it. I still don't understand why I don't need generations for allocating to-die-soon strings in a more efficient ways.

You are correct. Properly-implemented copying generational GCs are the only things that work to optimize allocation of strings, arrays, and objects judged to be escaping.

> So the majority of data is still stack (edit: heap)

It doesn't matter that the string's data lives somewhere else. It matters where what owns it lives. The string itself, that is, the pointer and length, both live on the stack, and so, it ends up working like a stack allocated value.

> I still don't understand why I don't need generations for allocating to-die-soon strings in a more efficient ways.

Because the string itself isn't on the heap, and therefore, a generation wouldn't help it.

How does that follow? If the string is a pointer to a heap array plus a length, then "it ends up working like a stack allocated value" would only be true if the underlying byte array was freed immediately when a scope ended. But that isn't the case because the heap is a GCd heap, Go doesn't have explicit frees.

This is one sort of reason why stack allocation isn't a cure-all - stack allocating a wrapper doesn't help you much if the bulk of the data is still in the heap. What can help, in this situation, is if the compiler can prove (or speculate that) the array is small and then scalar replace the array. However I think doing that sort of thing requires a profiling JIT compiler because statically proving array sizes ahead of time is very difficult.

I’m guess I am assuming that it would be freed at the end of the scope. As I said upthread, it’s entirely possible that I’m incorrect here.

This kind of thing happens in Ruby a lot; the VM will allocate stuff through malloc that never actually hits the GC; see Aaron Patterson's work.

I've never seen a GCd heap where you can explicitly free things outside of the Boehm conservative GC. I haven't seen any reference to Go supporting such a thing either.

I think all that happens when a string goes out of scope is that the byte array becomes eligible for GC.

That sounds trivial to fix... go cheats on all sorts of things with the built-in types (maps/slices/strings) that you can't do as a user of the language, seems they could easily implement something that explicitly frees the heap space when the string pops off... the free call could be inlined right into the compiled code by the compiler.

Go has a mark-and-sweep gc so in principle they can support explicit deallocation.

> This kind of thing happens in Ruby a lot; the VM will allocate stuff through malloc that never actually hits the GC; see Aaron Patterson's work.

IIUC there's a really huge difference here. Go can quickly allocate the byte array into the GC managed heap. MRI Ruby has to make a slow call to malloc(). Worse still, when collecting we can't just mark that memory available again. Ruby has to detect the type of each object and call free() accordingly.

> My understanding is, the string itself is on the stack, but the data is on the heap

What makes you say that? Pointers to stack are totally possible in Go; just because the `str` field is a pointer doesn't mean it points to the heap.

Reply on news.ycombinator.com