The JVM offers state of the art GCs, which allows for selecting the best tool for the job (throughput, latency, large heaps, etc.).
This is unlike the golang gc, which is tuned for latency at the expense of throughput, with no way of modifying its behavior without resorting to hacks like the article in the post.
Re:GC Fun at Twitch
by dwohnitmok on Saturday November 16, 2019 @12:02AM
(#21551107)
To Go's credit, it predates Shenandoah and ZGC, before which your only real option for low-latency GC on the JVM was Zing, which I don't think had too many people using it (I certainly have no personal experience with it). I can't say whether they were inspired by Go, but I do think that Go is responsible for bringing the desirability of low-latency GC, even at potentially high cost to throughput, to the forefront of the greater programming community's attention.
They could offer other ways to manage memory manually instead of just escape analysis, like GC enabled systems languages, but that is not the nature of Go's design.
Do you not consider G1 a low latency GC?
Re:GC Fun at Twitch
by dwohnitmok on Saturday November 16, 2019 @12:38PM
(#21553823)
When considering latency, it's still not in the same league as Shenandoah and ZGC. We still had occasional GC times over a second with G1 on some production systems several years ago IIRC.
Except when the best tool for the job is a language without GC at all.
Yes you can modify GC behaviour and it's one env variable, the fact that twitch didn't use it makes no sense.
Re:GC Fun at Twitch
by MaulingMonkey on Saturday November 16, 2019 @03:37AM
(#21551640)
The original blog post[1] does mention GOGC, and a list of pitfalls that made them prefer ballast / the pending heap size proposal[2] over it. Are they in error? Or do you find their reasoning unconvincing?
[1] https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...
The trade-off of the knob-less approach of Go's GC I suppose.