• Post Reply Bookmark Topic Watch Topic
  • New Topic

Performance of different types of Garbage Collectiors  RSS feed

 
Rob Ivan
Greenhorn
Posts: 29
Hibernate Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For the authors of "The Java Performance Companion":
Thank you for participating in the forum and best wishes on the success of your book.

What are some of performance differences and trade-offs between the four types of Java Garbage Collectors?
 
Bengt Rutisson
author
Greenhorn
Posts: 7
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The main trade off is between pause times and raw computation performance. The most efficient way of doing GC is to stop the running application and to the GC in one big chunk of work. This allows the GC to get a complete picture of the live objects in one go and thus it can perform the GC work very effectively. However, it means that the application is stopped and will appear frozen for the duration of the GC.

The opposite approach is to stop the application for only a short period and then try to do as much work as possible while the application is running. This will result in much shorter pauses, but the pauses will come more often, both because it is harder for the GC to do an efficient work and because more than one pause per GC cycle is needed to synchronise the GC work.

Basically this can be summarized as: do you want few but longer pauses or more but shorter pauses? This is the trade off that needs to be done. And it depends a lot on the behavior of the application. A batch job that runs to complete a task as fast as possible normally benefit from few but longer pauses. An application with tight user interaction normally feels more responsive with short but more frequent pauses.

In HotSpot the ParallelGC and SerialGC will give you fewer but longer pauses whereas G1 and CMS try to minimize the length of the pauses.

G1 is designed to try to make it possible to balance a bit between the two extremes. It has a configurable pause time target which allows it to be as efficient as possible while still trying to keep the pauses below the target time.
 
Winston Gutkowski
Bartender
Posts: 10573
65
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bengt Rutisson wrote:G1 is designed to try to make it possible to balance a bit between the two extremes. It has a configurable pause time target which allows it to be as efficient as possible while still trying to keep the pauses below the target time.

It would appear you're saying there are only two extremes to choose from, with some leeway for pre-selecting a "somewhere in between" value.

I have to admit to being very ignorant of how gc's actually work beyond the basics; but isn't there some way of making this choice dynamic as, for example, with a sort or compression algorithm?

Winston
 
Charlie Hunt
author
Greenhorn
Posts: 11
5
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
Bengt Rutisson wrote:G1 is designed to try to make it possible to balance a bit between the two extremes. It has a configurable pause time target which allows it to be as efficient as possible while still trying to keep the pauses below the target time.

It would appear you're saying there are only two extremes to choose from, with some leeway for pre-selecting a "somewhere in between" value.

I have to admit to being very ignorant of how gc's actually work beyond the basics; but isn't there some way of making this choice dynamic as, for example, with a sort or compression algorithm?

Winston


The biggest challenge with making the choice of which GC to dynamically / automatically to use by the JVM is that the JVM doesn't know whether you and application stakeholders are most interested in throughput, latency or memory footprint, or to what extent each is emphasized.

G1's makes an attempt at this by using a pause time target, aka MaxGCPauseMillis. If a person uses G1 and doesn't set -XX:MaxGCPauseMillis, MaxGCPauseMillis defaults to 200 ms. Based on that MaxGCPauseMillis and the size of the Java heap, G1 will attempt to meet that MaxGCPauseMillis.  However, due to GC algorithm differences and implementation details, when throughput is emphasized with little or no concern about response times / latency, Parallel GC will probably offer the best throughput performance. But, when latency becomes more important, Parallel GC runs into difficulties.
 
Winston Gutkowski
Bartender
Posts: 10573
65
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Charlie Hunt wrote:G1's makes an attempt at this by using a pause time target...

Ah, OK; that makes sense. I imagine there are also structural differences between pro-latency and pro-throughput algorithms that I don't fully understand.

It does seem odd though that we need to choose one or the other, and use static configuration parameters to tune them, because that seems to emphasize "how" over "what" - something we (or at least I) are notorious for warning newbies about.

To me, it would be nice to be able to tell a GC to prefer latency over throughput (or vice-versa) - maybe with some sort of "strength" indicator - without actually telling it how to do this (eg, max pause time).

Or am I living in cloud-cuckoo land?

Winston
 
Bengt Rutisson
author
Greenhorn
Posts: 7
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To me, it would be nice to be able to tell a GC to prefer latency over throughput (or vice-versa) - maybe with some sort of "strength" indicator - without actually telling it how to do this (eg, max pause time).


Yes, this makes a lot of sense. I would prefer something like -Xgc:throughput and -Xgc:pausetime over specifying a specific GC implementation. This would give the JVM enough information about the application while still allowing the JVM the freedom to pick an implementation that it finds suitable. That implementation may vary over different releases. (When I worked on the JRockit JVM we moved in this direction and the last release of JRockit had this feature.)

Dynamically selecting throughput or pausetime goal based on the max pause time switch is of course also possible, but heuristics like that tend to change over time and I can be difficult to work in a transparent way so users actually understand what is going on.

So, I think you are right, but currently you need to tell the HotSpot JVM exactly which GC implementation to use.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!