When not to use G1GC garbage collector?

Question

I looked into differences between various garbage collectors available for JVM. Here is the answer explaining the main differences between them : https://mcmap.net/q/359283/-when-to-choose-serialgc-parallelgc-over-cms-g1-in-java

Here it's said for G1GC that :

It's low pause / server style gc, mainly for large heap (> 4Gb).

We have a machine that has a total memory of 4 GB, and heap size allocated to JVM of 1 GB. I wanted to understand whether that would cause any issues for us, or would G1GC work out fine.

Roderica

Answer 1

The following summary is based on:

• Java /Java SE / 17 - HotSpot Virtual Machine Garbage Collection Tuning Guide: 5. Available Collectors

---

• If you have absolutely no interest in GC pause times, then use the serial collector (if you only have one core) or the parallel collector (if you have more than one core).

• If you need low pause times (with high probability), then use the G1 collector.

• If you need ultra-low pause times, and/or you have an extremely large heap, use the Z collector.

The old CMS collector has been removed as of Java 14.

---

Note that if you specify pause-time and/or throughput goals, you can leave the choice and tuning of the GC to the JVM. This is probably less risky than manually selecting and tuning the GC ... when you don't understand what you are doing.

This "behavior-based tuning" approach and its advantages are described here.

---

You asked:

We have a machine that has a total memory of 4 GB, and heap size allocated to JVM of 1 GB. I wanted to understand whether that would cause any issues for us, or would G1GC work out fine.

We can't tell you whether it would work out fine or not. It would depend on various aspects of your application's behavior and also on your expectations. For example, what "issues" would concern you if your application encountered them. I would recommend trying "behavior-based tuning" to start with, and see where that gets you.

Finally, setting a maximum heap size that is too small for the application will not end well ... no matter what GC you select.

Laird

Note that if you want string deduplication, the Serial GC is not an option (prior to JDK 18). Same for ZGC. – Gastrolith

And a few other things too. Like the fact that G1GC could be unpleasant if you have large short-lived objects that end up as "humongous object"s ... since they get tenured automatically. – Laird

Thanks for the answer! I will look into the "behaviour-based tuning" and see whether it works for us. Meanwhile, we also want low latencies, and therefore low GC pauses ~ 100ms. This I think might be a contradiction, as we also have low heap memory available. – Roderica

See the last sentence of my answer. It sounds like you may need a larger heap. – Laird

I fully agree, having enough memory is more important than the algorithm or any other tuning option. In fact, given enough memory, the GC’s fraction of the CPU time might be so low, that any tuning might be pointless. That’s why I recommend using Java 9 or newer, because compact strings can reduce the memory footprint significantly. Then, try G1GC with String Deduplication turned on, if this saves you another good chunk of memory, it will also help the performance. Therefore, depending on the application, this may even yield better throughput than the throughput collectors (prior to JDK 18). – Gastrolith

StephenC, @Gastrolith - Thanks a lot for these suggestions! Will look into these. – Roderica