undefined | Better HN

0 pointsklodolph3y ago0 comments

Looking at metrics from Go's garbage collector, what else do you want? GC pauses are damn low, and you'll see numbers in the sub 500μs range.

If I needed hard-realtime, I would avoid allocation entirely.

0 comments

kaba03y ago

Java's ZGC is the state-of-the-art on low-latency, high-throughput GCs, so it might be a better example.

Also, there are hard-real time JVMs -- but hard-realtime really doesn't mean what people often believe. These systems are usually much slower - that's the price they pay for having a fix higher bound on some latency requirement.

klodolphOP3y ago

Yes, the Java stuff is better. I picked Go as an example because you get very low pause times with no configuration. It's really common for Java apps to be misconfigured, especially when people start throwing GC tuning options at them--people who often don't understand what those tuning options do. For example, "the pauses are too long, let's increase the heap size".

kaba03y ago

Yeah I agree. Just for anyone who might stumble upon this, if you go with the default G1GC, pretty much just leave it as is. IF you experience some problem that you assume is due to the GC, you may try changing the singular config option of target pause time, which will tweak the GC on the latency-throughput spectrum (which are opposite ends of the same axis)

j / k navigate · click thread line to collapse

0 comments

kaba03y ago

Java's ZGC is the state-of-the-art on low-latency, high-throughput GCs, so it might be a better example.

klodolphOP3y ago

kaba03y ago

j / k navigate · click thread line to collapse