GC pauses can be hundreds of milliseconds. You could perhaps use a particular GC scheme that guarantees you never have more than a couple millisecond pause, but then you have lots of pauses. That might have unintended consequences as well. I'm also not sure that such GCs, like golangs, can really mathematically guarantee a minimum pause time.
You can often do this, although some runtimes treat it only as a hint and may ignore it (usually what you want). Go has some pretty strong guarantees on how long it will stop the world for, which makes it much less of an issue. But the best pause is still no pause, which means no GC.
I don't know this field, perhaps my bar is low because of Python lol, but Go's GC has very short GC pauses. So short that it makes non-GC'd usecases less attractive imo.
My big issue with Go's GC, or GC's in general, is consistency. Go's GC can still be variable in pause time iirc. But it's been ~3 years since i've worked in it - so maybe my memory is wrong :)
I consider 10ms pauses to fall into the "set the minimum time very high" branch of my statement. That is, if you can handle pauses of that magnitude there are already lots of GC options for you and golang is not adding much (that said 10 ms pause guarantees are much better than the current so more power to them).
Even 1ms pause ceilings drive people to non-GC options, so I think the "game changer" number is much lower than that.
This particular link has some info about that situation. GC pauses are deterministic starting Go1.5. Application code will run for at least 40ms out of every 50ms. The upper limit for the GC pause is 10ms and its typically lower.
Friendly PSA that modern Go has GC pauses under 1ms in almost all cases. That may still be a problem for your application, but it is a far cry from what people expect from other GC languages like Java.
There is a price you pay for this, you can even get 1 microsecond pause but how much work you will make in this 1 microsecond? You should measure total time spent in GC through x seconds instead of measuring one pause. If your task takes a lot of time then all those GC pauses times add together to the task execution time.
In practice those numbers you gave (provided by golang developers) are not always true. I know because I run apps written in Go in production.
Go’s GC pauses are on a microsecond scale. If you absolutely need to minimize latency at all costs, I’d be more worried that the Go compiler doesn’t optimize as aggressively as C/C++/Rust.
I've spent enough time writing games in various GCed languages, and GC has been an issue in all of them. It's less about the optimization of the actual pause time and more about trying to make sure that things are as deterministic as possible for debugging's sake. Though the pause is of course an issue as well.
> MO the big GC related issue is lack of determinism especially in the management of external resources.
This isn't a property of GCs per se; it's just that most GCs are optimized for throughput. Go's GC's pause times are on the order of 1ms, which might not be appropriate for every application, but it's probably fine for soft-realtime systems. There are a lot of other levers one could imagine as well, like semantics for demarcating critical sections.
My personal experience with microservices is to expect STW pauses in the 350 microsecond range. The best part is that it requires zero tunning or developer's attention while still being light on memory usage. Can't say the same for Java's default GC.
Properly written Go code (or even Java for that matter) will try to minimize allocations. For Java, unless I am mistaken pause-less GC is only offered by Azul - $$
He also mentioned that the JVM GC does a lot of online tuning, so the max pause times may drop over a longer run of the program. This is similar to the Racket GC, where the maximum pauses are >100ms at the start of the run, but converge to around 20ms as the program continues to run.
It would be nice to run the benchmarks for a longer period of time, and only measure max pause times once this "ramp up" period is over.
i've literally experienced worse pauses from java (sometimes surpassing 30s) GC due to allocation. granted it was pre the latest G1 GC. but they absolutely exist and many companies run on older versions of java.
and I doubt you see pauses in golang longer than 30ms. proof please.
reply