Go does not need a Java-style GC
erik-engheim.medium.com
Go does not need a Java-style GC
1–10 of 226 posts
Re: Go does not need a Java-style GC
#2I'm cautious about believing this sort of claim because I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be ready. However, the article convincingly explains who Java has a greater need for a compacting GC - it creates more garbage. This doesn't necessarily mean Go won't benefit from having a generational, compacting GC at some point, for some applications.
Re: Go does not need a Java-style GC
#3I'm cautious about believing this sort of claim because I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be ready. However, the article convincingly explains who Java has a greater need for a compacting GC - it creates more garbage. This doesn't necessarily mean Go won't benefit from having a generational, compacting GC at some point, for some applications.
Even if it doesn't need specifically a compacting QC having a swappable more tunable one might still be a big deal for people who need something other than the current GC. Like a simple example is the Discord article about how their use case could not work with Go because it always ran the GC every two minutes. If they could optionally disable that feature they theoretically could have kept using Go instead of rewriting to Rust.
Re: Go does not need a Java-style GC
#4What it needs is Rust style static lifetime management.
Re: Go does not need a Java-style GC
#5I'm cautious about believing this sort of claim because I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be ready. However, the article convincingly explains who Java has a greater need for a compacting GC - it creates more garbage. This doesn't necessarily mean Go won't benefit from having a generational, compacting GC at some point, for some applications.
> I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be ready
Hey, us generics-naysayers are still out here (grumbling)! :)
Re: Go does not need a Java-style GC
#6> In a multithreaded program, a bump allocator requires locks. That kills their performance advantage.
Java uses per-thread pointer bump allocators[1]
> While Java does it as well, it doesn’t utilize this info to put objects on the stack.
Correct, but it does scalar replacement[2] which puts them in registers instead
> Why can Go run its GC concurrently and not Java? Because Go does not fix any pointers or move any objects in memory.
Most java GCs are concurrent[3], if you want super low pauses you can get those too[4][5]. Pointers can get fixed while the application is running with GC barriers
[1]: https://shipilev.net/jvm/anatomy-quarks/4-tlab-allocation/
[2]: https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacemen...
[3]: https://shipilev.net/jvm/anatomy-quarks/3-gc-design-and-paus...
Re: Go does not need a Java-style GC
#7I'm cautious about believing this sort of claim because I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be ready. However, the article convincingly explains who Java has a greater need for a compacting GC - it creates more garbage. This doesn't necessarily mean Go won't benefit from having a generational, compacting GC at some point, for some applications.
The JVM world right now has quite a few GCs and your choice essentially dictates your program's performance tradeoffs.
But I'm not sure if there will ever be a point where this is true for Go considering how little gets into the stack compared to Java.
Re: Go does not need a Java-style GC
#8I'm a bit skeptical.
Yes, Go has value types and pointers. But whether you need a modern GC will undoubtedly depend a lot on the type of algorithms you need to execute. Also, it's great that you can implement (some form of) allocators, and that will definitely help for many algorithms, but that's definitely a case of tradeoff between convenience and readability. Similarly, unless I'm mistaken, TCMalloc "solves" fragmentation in two cases: either allocations are small (very common) or memory allocation maps neatly to threads (much less common). That's two good cases to have, but I wouldn't count on it solving memory allocation on its own for, say, a browser engine or a videogame.
Oh, and hasn't Java's GC been fully concurrent for a while now?
That being said, revisiting the assumptions made by Java (and other languages) is a very good idea.
Re: Go does not need a Java-style GC
#9I'm cautious about believing this sort of claim because I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be ready. However, the article convincingly explains who Java has a greater need for a compacting GC - it creates more garbage. This doesn't necessarily mean Go won't benefit from having a generational, compacting GC at some point, for some applications.
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.
Re: Go does not need a Java-style GC
#10Cool article, I'm not sure I agree with the headline.
I used to write low-scale Java apps, and now I write memory intensive Go apps. I've often wondered what would happen if Go did have a JVM style GC.
It's relatively common in Go to resort to idioms that let you avoid hitting the GC. Some things that come to mind:
* all the tricks you can do with a slice that have two slice headers pointing to the same block of memory [1]
* object pooling, something so common in Go it's part of the standard library [2]
Both are technically possible in Java, but I've never seen them used commonly (though in fairness I've never written performance critical Java.) If Go had a more sophisticated GC, would these techniques be necessary?
Also Java is supposed to be getting value types soon (tm) [3]
[1] https://ueokande.github.io/go-slice-tricks/