2

I looked into differences between various garbage collectors available for JVM. Here is the answer explaining the main differences between them : https://stackoverflow.com/a/54619838/5345646

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.

Mooncrater
  • 4,146
  • 4
  • 33
  • 62

1 Answers1

7

The following summary is based on:

  • 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 you can leave choice and tuning of the GC to the JVM is you specify pause-time and/or throughput goals. 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.

Also, be aware that setting a max heap size that is too small for the application will not end well ... no matter what GC you select.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • 2
    Note that if you want string deduplication, the Serial GC is not an option (prior to JDK 18). Same for ZGC. – Holger May 18 '22 at 14:23
  • 2
    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. – Stephen C May 18 '22 at 14:33
  • 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. – Mooncrater May 19 '22 at 04:32
  • 2
    See the last sentence of my answer. It sounds like you may **need** a larger heap. – Stephen C May 19 '22 at 04:48
  • 3
    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). – Holger May 19 '22 at 07:41
  • StephenC, @Holger - Thanks a lot for these suggestions! Will look into these. – Mooncrater May 19 '22 at 11:52