• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

The Java Performance Companion: garbage collection

 
Author
Posts: 285
12
Scala IntelliJ IDE Netbeans IDE Python Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetings Charlie et al.

So, I figure I owe a decently thought out question for a shot at your book, here's what I have:

Background: Each new garbage collection policy has tended to bring with it significant shifts in how programmers should think about object allocation and lifetime. My first experiments with G1 were pretty disappointing; overall GC CPU fractions went up significantly, and stop-the-world times didn't really seem to reduce much either. I'm acutely aware, however, that my tests were run on fairly small machines, and I have a feeling that G1 is targeted primarily at large systems with many CPUs and lots of memory (rather than an i7 CPU with 8 hardware threads and 16Gb RAM).

So, my question is this: what are reasonable expectations for improvement in GC behavior, and what running conditions (both system and programmer behavior) are most conducive to seeing those improvements?

Cheers,
Simon
 
author
Posts: 11
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Great to hear from you Simon. Also thanks for your responses to other questions as well. :-)

Your question kind of has hidden between the lines that G1 was initially developed with the intent of dealing with larger Java heaps.  And, that is true. Our primary focus with G1 initially was to target the larger Java heaps and keeping GC pauses in that area of 200 ms - 500 ms. We also knew there would be tradeoffs in the areas of memory footprint, throughput and CPU usage with a lower GC pause time goal. For instance, on a large Java heap we would expect that Parallel GC versus G1 likely would have higher throughput, higher latency, lower memory footprint and probably use less memory than G1. But, G1 would have lower latency, or a more balanced tradeoff between throughput, latency, footprint and CPU usage.

In more recent updates of JDK 8, and in the under development of JDK 9, we have started to focus on lower latency and smaller Java heaps.

To your specific question on "reasonable expectations for improvement in GC behavior ...", my initial reaction is to look at what was written in Java Performance on tuning the JVM step by step. The general notion from selecting an appropriate GC was the first start with Parallel GC, and if it could meet the application's performance goals as they related to throughput, latency and footprint, to use Parallel GC. But, if latency was too great to tolerate, even after attempting to tune Parallel GC, then the next step suggested step was to move to CMS GC. This is where I would modify that suggestion and also suggest to move to G1 GC. When it comes to tuning G1 GC, tuning it is quite different from the approaches to tuning Parallel GC and even CMS GC. That was one of the motivations we had for content in the Java Performance Companion, i.e. to offer readers the information and "how to" tune G1. I think G1 is easier to tune than CMS GC, but in fairness I am also very familiar G1 GC.  I might also mention that because improvements continue to be made to G1, perhaps if you have evaluated G1 at some point time, it may be that some enhancement that has been done since that evaluation, or a future enhancement may address what you have seen.

Might also take this opportunity to say that both Bengt and Monica may have some additional insight to add.
 
Simon Roberts
Author
Posts: 285
12
Scala IntelliJ IDE Netbeans IDE Python Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for this Charlie, I think the bottom line is clear. I'll buy the book and try some new experiments. It's true, I should 'fess up, that it was quite a while ago that I made my experiments (some version of JDK 1.7), so it's surely time to try again.

As a "takeaway" is it fair to assume that the benefit of G1 is most pronounced (when compared with other collectors) with larger heaps, or is that not reliably true either?
 
Charlie Hunt
author
Posts: 11
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Simon Roberts wrote:Thanks for this Charlie, I think the bottom line is clear. I'll buy the book and try some new experiments. It's true, I should 'fess up, that it was quite a while ago that I made my experiments (some version of JDK 1.7), so it's surely time to try again.

As a "takeaway" is it fair to assume that the benefit of G1 is most pronounced (when compared with other collectors) with larger heaps, or is that not reliably true either?



Yes, I would say that is true for most applications, and here's my reasoning (you maybe thinking similarly?) ...   With a smaller Java heap, with Parallel GC or Serial GC, the time to collect old generation (or we could just say the time to do a full GC), is generally not as lengthy as what we would see with a larger Java heap.  And, that lengthy pause time is what usually ends up exceeding some SLA wrt latency, whether that be worst case pause time, or something like a 99th or 95th percentile.

I might add that will Parallel GC, if you can meet the pause time goals with it, then you will realize the best throughput with it. So, if you can meet pause time goals with Parallel GC, it will give you the best overall performance, both throughput and latency. I think you will find that consistent with what's in the step by step tuning chapter in Java Performance.  With the addition of G1, wrt the step by step tuning approach, G1 comes into that step by step tuning in the case where Parallel GC is not able to those pause time goals, (and that tends to be with larger Java heaps), then you move to G1, or you could move to CMS GC.  I suggest G1 for the following reasons; CMS is harder to tune, CMS has the potential to fragment the old generation space since concurrent collection does not compact the old generation, (when fragmentation is severe enough, a full GC will occur), and there are CMS deprecation discussions underway at OpenJDK.
 
reply
    Bookmark Topic Watch Topic
  • New Topic