4 ms·

> This makes me very thankful for the work that the Go team has put into the go GC. Has the Go team hit on some GC algorithm that has escaped the notice of the

by pkulak 4y ago

> This makes me very thankful for the work that the Go team has put into the go GC. Has the Go team hit on some GC algorithm that has escaped the notice of the entire compiler-creating world since 1995? Not to disparage Go at all, it's got brilliant people working on it, but you could boil the oceans at this point with the effort from the brilliant folks who have been working on JVM garbage collection for the last 20+ years.

Scaevolus 4y ago
The Go team has members with decades of experience writing garbage collection algorithms, including on the JVM, so it's not starting from scratch. Go has value types and stack allocation that allow it to create _far_ less garbage than Java and means its heap objects violate the generational hypothesis-- because shortlived objects tend to stay on the stack. This means that the Go GC can comfortably operate with far less GC throughput than typical Java programs. https://go.dev/blog/ismmkeynote https://go.dev/blog/ismmkeynote
- pkulak 4y ago
  Java has done escape analysis and scalar replacement since 6.
Mawr 4y ago
> Has the Go team hit on some GC algorithm that has escaped the notice of the entire compiler-creating world since 1995? It's like the saying about recycling: "1. Reduce 2. Reuse 3. Recycle". Just like in real life, it's far better to never have to go to all the way down to #3. If you never generate garbage in the first place, you won't have to waste resources cleaning it up. So it's less about how good the actual Go GC is and more that the language itself greatly discourages wasting memory via aggressive stack allocation, value types, and an allocation-conscious culture.
dontlaugh 4y ago
It actually has very poor throughout when compared to almost any JVM GC. This is mitigated somewhat by the commonality of value types. The major advantage is mostly predictably short pauses. For web services it’s a reasonable trade off, but it can be a problem that the GC can’t be tuned for something else.

by pkulak 4y ago

Scaevolus 4y ago

The Go team has members with decades of experience writing garbage collection algorithms, including on the JVM, so it's not starting from scratch. Go has value types and stack allocation that allow it to create _far_ less garbage than Java and means its heap objects violate the generational hypothesis-- because shortlived objects tend to stay on the stack. This means that the Go GC can comfortably operate with far less GC throughput than typical Java programs. https://go.dev/blog/ismmkeynote https://go.dev/blog/ismmkeynote

pkulak 4y ago
Java has done escape analysis and scalar replacement since 6.

Mawr 4y ago

> Has the Go team hit on some GC algorithm that has escaped the notice of the entire compiler-creating world since 1995? It's like the saying about recycling: "1. Reduce 2. Reuse 3. Recycle". Just like in real life, it's far better to never have to go to all the way down to #3. If you never generate garbage in the first place, you won't have to waste resources cleaning it up. So it's less about how good the actual Go GC is and more that the language itself greatly discourages wasting memory via aggressive stack allocation, value types, and an allocation-conscious culture.

dontlaugh 4y ago

It actually has very poor throughout when compared to almost any JVM GC. This is mitigated somewhat by the commonality of value types. The major advantage is mostly predictably short pauses. For web services it’s a reasonable trade off, but it can be a problem that the GC can’t be tuned for something else.