3 ms·

I was talking about technology state of the art, not out-of-the-box experience. OpenJDK's default collector - parallel or G1GC, depending on version - is not t

I was talking about technology state of the art, not out-of-the-box experience. OpenJDK's default collector - parallel or G1GC, depending on version - is not the best available among JVMs and if your goal is pause times then yes, it will be worse than Go's. But if you switch to say C4 or ZGC you'll get comparable pause times and compacting on top and being able to scale to terabyte heaps. 10 years ago we had Metronome and CMS, which are more comparable to Go's collector. And pause-times are not everything. Throughput and fragmentation resistance matter too. Compacting collectors fare much better on the latter metric. I don't know how the former is now, but those slides talked about 25% GC overhead in older versions of Go, that's utterly terrible. Go is facing one challange that java doesn't: internal pointers. But the CLR's collectors have to deal with those too, so that's not terra incognita either.

hu3 8y ago
Of course gains are to be expected when switching from Java's default GC to something specialized. > 25% GC overhead in older versions of Go, that's utterly terrible. 25% overhead of what? And compared to what? Just throwing numbers in the air and saying it's terrible makes no sense. The only 25%'s if could find in the slide were these: https://blog.golang.org/ismmkeynote/image6.png https://blog.golang.org/ismmkeynote/image6.png 2014 Go: 25% of CPU used by GC 2018 Go: 25% of CPU used during 2x STW GC of < 500 microseconds So even if STW GC occurred as frequent as every second (which it doesn't in my use cases), this would amount to 0.025% of the CPU being used for GC, not 25%.
- the8472 8y ago
  The 2014 numbers read to me that 25% of all CPU cycles are spent on GC. If you re-read my previous post I was talking about that old version. The point was that Go started improvements from a fairly bad place, were gains are still relatively easy to obtain. > Of course gains are to be expected when switching from Java's default GC to something specialized. So? That's irrelevant for what's state of the art.
  - hu3 8y ago
    I re-read our conversation thread to understand our communication mismatch and indeed you were taking about Go's GC not being novel, which it isn't. I apologize for the unproductive conversation, it's all on me.

hu3 8y ago

Of course gains are to be expected when switching from Java's default GC to something specialized. > 25% GC overhead in older versions of Go, that's utterly terrible. 25% overhead of what? And compared to what? Just throwing numbers in the air and saying it's terrible makes no sense. The only 25%'s if could find in the slide were these: https://blog.golang.org/ismmkeynote/image6.png https://blog.golang.org/ismmkeynote/image6.png 2014 Go: 25% of CPU used by GC 2018 Go: 25% of CPU used during 2x STW GC of < 500 microseconds So even if STW GC occurred as frequent as every second (which it doesn't in my use cases), this would amount to 0.025% of the CPU being used for GC, not 25%.

the8472 8y ago
The 2014 numbers read to me that 25% of all CPU cycles are spent on GC. If you re-read my previous post I was talking about that old version. The point was that Go started improvements from a fairly bad place, were gains are still relatively easy to obtain. > Of course gains are to be expected when switching from Java's default GC to something specialized. So? That's irrelevant for what's state of the art.
- hu3 8y ago
  I re-read our conversation thread to understand our communication mismatch and indeed you were taking about Go's GC not being novel, which it isn't. I apologize for the unproductive conversation, it's all on me.