5 ms·

Go creates less garbage and also stack allocates things using escape analysis which as the article explains, is effectively a form of generational garbage colle

Go creates less garbage and also stack allocates things using escape analysis which as the article explains, is effectively a form of generational garbage collection.

kaba0 5y ago
As far as I know (I’m not too familiar with Go), Go mostly stack allocates based on the developer’s intent, eg. by using structs. Java doesn’t (yet) have an option for value types that can be reliably stack allocated, so it resorts to very complex escape analysis. Calling the former escape analysis is a bit misleading imo, even if technically true.
- vore 5y ago
  Go is a little more elaborate than that: if a value is initialized as a pointer-to-struct (e.g. foo := &Foo{...}) and it doesn't escape the function, Go will allocate it as if were a value type.
  - JulianMorrison 5y ago
    You can stack-allocate in C, with alloca() or by taking the address of a local, and use it like a pointer. So long as you're extremely sure nothing is going to hang onto the pointer beyond the lifetime of that stack frame, it's fine. Same thing with Go, except that the compiler makes the decision.
masklinn 5y ago
However it's a weak one, the stack allocation acts as a form of extremely limited nursery, but lots of "escaping" objects could well fit into a nursery, to say nothing of "heap" objects (like strings and slices) which always trigger heap allocations. Furthermore AFAIK most generational GCs have 3 generations, not 2 (let alone 1.5). It does make the tradeoff more complicated, a generational GC is not simple (especially in a language with ubiquitous mutability), but the casual dismissals are... troubling. And that's before mentioning the regularly problematic lack of tuning knobs of the Go GC, also often dismissed as "java concerns" (which Go users have to work around using ugly hacks when hit, because they don't have tuning knobs).
- geodel 5y ago
  > Go users have to work around using ugly hacks when hit, because they don't have tuning knobs Yeah, Java users just have to hire Java performance tuning experts from sprawling Java perf consulting cottage industry. Can't get much simpler than that.
  - erik_seaberg 5y ago
    Even if you need an expert, it’s safer and cheaper than rewriting the critical path several times hoping for better behavior.
    - geodel 5y ago
      Well, I guess YMMV. I have seen more success by rewriting slow stuff.
    - socialdemocrat 5y ago
      I don't get this attitude. Optimizing your code is a pretty normal thing to do. Running performance analysis, finding hotspots and tuning them. I would prefer tuning my code over tuning a garbage collector as tuning code is more transparent. It depends on your background. If you are used to native code development like me, then you are used to thinking about how code get compiled and how memory is used. I suppose in the Java world, these things are treated as black boxes. The downside of that is that you get no stability under your feet. Everything is up to whatever garbage collector you use and how that is tuned. I am sure many people like that, but I would prefer to be in control over my own code and understand why it performs and doesn't perform. I want optimization to be explicit rather than based on lots of magical tweaking by some GC expert.
  - azth 5y ago
    That's because Java is used to run huge systems (dare I say, "enterprise scale"), whereas golang, especially today with microservices" is not seen in such areas. However, we still see issues in golang like * https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to... * https://news.ycombinator.com/item?id=21670110 https://news.ycombinator.com/item?id=21670110

Go creates less garbage and also stack allocates things using escape analysis which as the article explains, is effectively a form of generational garbage collection.

kaba0 5y ago

As far as I know (I’m not too familiar with Go), Go mostly stack allocates based on the developer’s intent, eg. by using structs. Java doesn’t (yet) have an option for value types that can be reliably stack allocated, so it resorts to very complex escape analysis. Calling the former escape analysis is a bit misleading imo, even if technically true.

vore 5y ago
Go is a little more elaborate than that: if a value is initialized as a pointer-to-struct (e.g. foo := &Foo{...}) and it doesn't escape the function, Go will allocate it as if were a value type.
- JulianMorrison 5y ago
  You can stack-allocate in C, with alloca() or by taking the address of a local, and use it like a pointer. So long as you're extremely sure nothing is going to hang onto the pointer beyond the lifetime of that stack frame, it's fine. Same thing with Go, except that the compiler makes the decision.

masklinn 5y ago

However it's a weak one, the stack allocation acts as a form of extremely limited nursery, but lots of "escaping" objects could well fit into a nursery, to say nothing of "heap" objects (like strings and slices) which always trigger heap allocations. Furthermore AFAIK most generational GCs have 3 generations, not 2 (let alone 1.5). It does make the tradeoff more complicated, a generational GC is not simple (especially in a language with ubiquitous mutability), but the casual dismissals are... troubling. And that's before mentioning the regularly problematic lack of tuning knobs of the Go GC, also often dismissed as "java concerns" (which Go users have to work around using ugly hacks when hit, because they don't have tuning knobs).

geodel 5y ago
> Go users have to work around using ugly hacks when hit, because they don't have tuning knobs Yeah, Java users just have to hire Java performance tuning experts from sprawling Java perf consulting cottage industry. Can't get much simpler than that.
- erik_seaberg 5y ago
  Even if you need an expert, it’s safer and cheaper than rewriting the critical path several times hoping for better behavior.
  - geodel 5y ago
    Well, I guess YMMV. I have seen more success by rewriting slow stuff.
  - socialdemocrat 5y ago
    I don't get this attitude. Optimizing your code is a pretty normal thing to do. Running performance analysis, finding hotspots and tuning them. I would prefer tuning my code over tuning a garbage collector as tuning code is more transparent. It depends on your background. If you are used to native code development like me, then you are used to thinking about how code get compiled and how memory is used. I suppose in the Java world, these things are treated as black boxes. The downside of that is that you get no stability under your feet. Everything is up to whatever garbage collector you use and how that is tuned. I am sure many people like that, but I would prefer to be in control over my own code and understand why it performs and doesn't perform. I want optimization to be explicit rather than based on lots of magical tweaking by some GC expert.
- azth 5y ago
  That's because Java is used to run huge systems (dare I say, "enterprise scale"), whereas golang, especially today with microservices" is not seen in such areas. However, we still see issues in golang like * https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to... * https://news.ycombinator.com/item?id=21670110 https://news.ycombinator.com/item?id=21670110