Hacker News Reader

Comment by bestinterest | Hacker News Reader

This might be an odd question but how often does garbage collection run and whats the usual time taken over a period of time?

Say I'm doing a drawing/game app and creating a few hundred heap objects a second that need to get garbage collected.

I have no idea on how often GC is run on a typical app and how much real time it takes over say an hour of an semi complex app running on average. It obviously depends on the app but I do not even have a number average cost of a GC language for some typical web app.

I only know 'GC's are bad' because the 100s of HackerNews comments dismissing languages because they have a GC for some reason rather than hard examples of them eating up time.

View on HN

GC can be very efficient when considering the average cost over time, and is faster than reference counting for instance. It also can have nice features such as heap compaction which you can’t easily do with manual memory management.

But the main thing most folks have problems with is the random latency spikes you get with GC. The GC can start at any time in most languages, and might stop all threads in your program for maybe dozens or hundreds of ms. This would be visible to users if you are rendering frames at a constant rate in a game, since each frame takes only around 16 ms in a 60 FPS game.

That’s what’s exciting about changes like what they are doing with ZGC. They are saying the max garbage collection time is 0.5 ms in normal situations, and the average time is even lower. Most games can accommodate that without a problem.

FYI, this is also important for web servers as well. Some web servers have a huge amount stored in memory, and the GC could take hundreds of ms or even multiple seconds to collect at random times in extreme cases. This can make a web request take perceptibly longer.

Also, if you have multiple machines communicating with one another and randomly spiking in latency due to GC, then worst case latency can add up to pretty terrible numbers if you are not careful.

GC is a memory management technique with tradeoffs like all the others.

GC has many different implementations, with widely ranging properties. For example, the JVM itself currently supports at least 3 different GC implementations. There are also different types of GC's, so for example in a generational garbage collection system you'll typically see two or three generations of GCs, depending on the generation (how many GC cycles it has survived) of the objects it collects. The shortest GC's in those systems are usually a couple milliseconds, while the longest ones can be many seconds.

GC isn't always a problem. If your application isn't latency sensitive, it's not a big deal. Though if you tune your network timeouts to be too low, even something that is not really latency sensitive can have trouble because of GC causing network connections to timeout. Even if it is a latency sensitive applicatoin, if GC "stop the world" pauses - pauses that stop program execution, are short it can be OK.

One reason you'll see people say GCs are bad is for those latency sensitive applications. For example, I previously worked on distributed datastores where low latency responses were critical. If our 99th percentile response times jumped over say 250ms, that would result in customers calling our support line in massive numbers. These datastores ran on the JVM, where at the time G1GC was the state of the art low-latency GC. If the systems were overloaded or had badly tuned GC parameters, GC times could easily spike into the seconds range.

Other considerations are GC throughput and CPU usage. GC systems can use a lot of CPU. That's often the tradeoff you'll see for these low-latency GC implementations. GC's also can put a cap on memory throughput. How much memory can the GC implementation examine with how much CPU usage with what amount of stop-the-world time tends to be the nature of the question.

> Say I'm doing a drawing/game app and creating a few hundred heap objects a second that need to get garbage collected.

Was literally my job ten years ago to optimize this and I was struggling with a GC'd language with a proprietary implementation (flash+actionscript).

The problem is not with hundreds of heap objects per-frame, the problem is that they would accumulate to the tens of thousands before the first GC trigger happens.

And the GC trigger might happen in the middle of drawing a frame, even worse, at the end of drawing a frame (which means even a 10ms pause means you miss the 16ms frame window at 60fps).

The problem that most people had was that this was unevenly distributed and janky to put it in the lingo. So you'd get 900 frames with no issues and a single frame that freezes.

So most of the problem people have with GC pauses is the unpredictability of it and the massive variations in the 99th percentile latency in the system, making it look slower than it actually is.

Most of the original GC implementations scale poorly as the memory sizes went up and the amount of possible garbage went up, until the GC models started switching over the garbage-first optimizations, thread-local alloc buffers and survivor generation + heap reserves etc (i.e we have lots of memory, our problem is with the object walking overheads - so small objects with lots of references is bad).

The GC model is actually pretty okay, but it is still unpredictable enough that tuning the GC or building an application on top of a GC'd language which has strict latency requirements is hard.

However, as a counterpoint - OpenHFT.

Clearly it is possible, but it takes a lot of alignment across all the system layers, but at that point you might as well write C++ because it is not portable enough to run anywhere.

It really depends on application and complexity of object graph. Short lived object usually have low overhead. Long lived objects with huge heap may cause a problem.

In past GC had bad reputation for increased and unpredictable latencies. In old JVMs GC would pause execution to traverse object graph.

In general do not worry about GC, unless you run into performance issues. If performance is a problem, run continuous profiler such as Flight Recorded. It has very little overhead.

And in most cases it isn't GC which is the problem, but the program doing too many heap allocations. Cutting heap allocations down improves the speed of most programs, with or without GC.

"It depends." There is no such thing as a singular "GC", tradeoffs are everywhere, and there are more relevant metrics than just average collection time.

I recommend this paper from 1992 for an introduction of what types of GC techniques exist https://www.cs.rice.edu/~javaplt/411/15-spring/Readings/wils... It's good basic knowledge.

If you get through that you might want to peruse more modern techniques: https://gchandbook.org/ I think the book's a lot drier/harder to understand than the paper though.

As a counter-signal consider my comment to be dismissive of languages without a GC, because life is too short to deal with manual memory management outside of where you really need to do it, and in those cases anyway there are techniques you can use in GC languages for it that reduce to about the same effort as manual memory management.

Do you have any links about recent developments / GC algorithms? Thanks.

Not on hand, sorry, I don't follow it that closely. My advice if you're interested in ultra low pause time designs is to look more at ZGC and maybe Shenandoah, and look for detailed comparisons to the other JVM GCs (especially G1 which has also seen some advances since it originally was designed). I'm not aware of any other ecosystem besides the JVM's that's had as much GC innovation in the last 15 years (one has to include Azul's now-old proprietary work to get that time span since ZGC is just now catching up to it) -- not to mention exposure to real and varied workloads. And if you just restrict to OpenJDK, the last 2 or 3 years have seen a lot of improvement that even many Java programmers still have no idea of if they're still stuck in Java 8 land.

After some research I couldn't really find much of an answer.

The thing about GC is you either don't care at all, or you don't want it at all. There's rarely a case where you know how many GC cycles you can handle in a certain period. Web dev, GC all you want. Games can handle GC but its likely you'll need to be cognitive of memory use. Embedded stuff doesn't have enough memory to utilize a GC.

I'm sure why GC languages get so much hate. I do a lot with C# and the runtime gives a few options for controlling allocations and accessing memory, so I can usually get it to be fast enough.

Reply on news.ycombinator.com