4 ms·

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 g

by apta 7y ago

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.

dwohnitmok 7y ago
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.
- pjmlp 7y ago
  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.
- astral303 7y ago
  Do you not consider G1 a low latency GC?
  - dwohnitmok 7y ago
    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.
Thaxll 7y ago
Yes you can modify GC behaviour and it's one env variable, the fact that twitch didn't use it makes no sense.
- MaulingMonkey 7y ago
  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-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i... [2] https://github.com/golang/go/issues/23044 https://github.com/golang/go/issues/23044
tus88 7y ago
Except when the best tool for the job is a language without GC at all.

by apta 7y ago

dwohnitmok 7y ago

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.

pjmlp 7y ago
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.
astral303 7y ago
Do you not consider G1 a low latency GC?
- dwohnitmok 7y ago
  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.

Thaxll 7y ago

Yes you can modify GC behaviour and it's one env variable, the fact that twitch didn't use it makes no sense.

MaulingMonkey 7y ago
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-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i... [2] https://github.com/golang/go/issues/23044 https://github.com/golang/go/issues/23044

tus88 7y ago

Except when the best tool for the job is a language without GC at all.