Hacker News Reader

Comment by lumost | Hacker News Reader

Modern low latency GC like Shenandoah/golang and to a lesser extent g1 mitigate the pause issue pretty substantially.

It’s impossible to verify, but some of the workarounds in very large c apps seem like they have about as much overhead as A modern GC.

View on HN

At a prior job (writing database kernels in C++), code commits were automatically rejected if any core operation had an observed tail latency of 1 millisecond under stress tests. Also a way to become unfortunately familiar with storage firmware behavior. A GC with a worst-case latency in low milliseconds is a big improvement over the bad old days I remember, but that is still too high for data infrastructure performance-engineering.

The effectiveness of some key optimizations were sensitive to how tight we could make tail latencies for important operations, so a GC always had an unacceptable cost to the extent it occasionally introduced a stall at an inopportune moment. If GC stalls were more like 10 microseconds, consistently, that would be much more viable. I have no idea if that is realistically achievable.

I don't see why a GC couldn't be told avoid stalling in critical code paths. From a practical standpoint, non-generational GCs have no hard requirement to ever stall.

But can them in practice, and ten years ago when $PROJECT was started and a tech stack had to be chosen ?

Given how long GC enabled languages with manual memory management capabilities do exist, 10 years ago there were already options available, D would have been an option.

As usual, it depends.

GC's don't exist in abstract, and there are plenty of GC enabled languages that also have value types and manual memory management capabilities.

There is no need to throw everything away when the right GC enabled language is chosen in first place.

JVM’s ZGC promises sub-millisecond pauses regardless of heap size, so I’m fairly sure it is no longer applicable to say that GC’s are incompatible with this type of workload. Though of course where these things really matter one should also look at the underlying OS and at least pin the process to fixed cores, as the OS scheduler may cause bigger latencies than the GC.

Though for completeness’s sake I will add that in case of the JVM, variable tail latency still can be experienced due to the JIT compiler.

That's probably acceptable for most use cases.

On Google Earth, even sub-millisecond pauses would have been too much, we had to fight pretty hard for every sliver of performance we could get.

That's not acceptable in any GUI or multimedia case, which is, by far, what most people do with their computers. Current screens have a 240hz refresh rate, deadline for a frame is 4ms (and more realistically 2-3ms because your program isn't the only one hogging the cpu) ; 1ms GC stall is up to half of your time budget.

You missed ZGC, that’s great.

Shenandoah and ZGC are roughly at par with each other (although ZGC has greater reach because Oracle), but yes that is true with ZGC as well.

Reply on news.ycombinator.com