Oracle Proposes G1 as the Default Garbage Collector for Java 9
- Share
-
- |
Read later
Reading List
Oracle is considering including JEP 248, making G1 the default garbage collector on server configurations, into the list of JEPs targeting Java 9. The decision has triggered some debate among the Java community, with many arguing that the Concurrent Mark and Sweep (CMS) collector could have been more suitable.
Should the decision go ahead, G1 would replace Parallel GC as the default choice for server configurations. As described in a Memory Management Whitepaper published by Oracle, Parallel GC was designed to maximise application throughput via infrequent (although potentially long) Stop-The-World (STW) pauses. By minimising total computational time used by the collector, Parallel GC is less disruptive in the long run, therefore providing better overall performance. This collector is ideally suited for applications where response time isn’t an issue, for example batch processing.
On the other hand, Garbage First (G1) is designed to minimise STW pauses at the expense of a higher computational cost, as previously explained on InfoQ by Monica Beckwith, former performance lead for G1. G1 is better suited for low-latency applications such as web servers, which in turns represents the motivation presented by Stefan Johansson in the JEP:
Limiting GC pause times is, in general, more important than maximizing throughput. Switching to a low-pause collector such as G1 should provide a better overall experience, for most users, than a throughput-oriented collector such as the Parallel GC, which is currently the default.
The controversy arises from the fact that the CMS was introduced in HotSpot for the same purpose, and is in fact described by Oracle as “designed for applications that prefer shorter garbage collection pauses and that can afford to share processor resources with the garbage collector while the application is running”. Many publicly available benchmarks indicate that CMS tends to outperform G1 in applications of relatively small footprint, which matches Oracle’s description of G1 as suitable for server applications with heaps of 6GB or more.
Performance expert Kirk Pepperdine highlighted in a recent communication that Google had contributed a number of improvements to CMS that never made it to HotSpot. He also added that although G1 is probably the better choice in the long run, Oracle’s engineering priorities have deprived the community from a better experience with CMS.
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Community comments
my experience ..
by
Rüdiger Möller
Posted
Why would no one consider Azul?
by
Kristen Gill
Posted
Re: Why would no one consider Azul?
by
William Smith
Posted
Re: Why would no one consider Azul?
by
Evan Haxton
Posted
Re: Why would no one consider Azul?
by
William Smith
Posted
Why would no one consider Azul?
by
Kristen Gill
Posted
Overhead of Garbage Collection
by
Shamal Jayakody
Posted
Overhead of Garbage Collection
by
Shamal Jayakody
Posted
my experience ..
by
Rüdiger Möller
For many apps, a properly tuned CMS delivers significant lower pauses and similar if not better throughput compared to G1, however this requires application specific CMS tuning. So G1 is probably a reasonable option to be run as a default.
Why would no one consider Azul?
by
Kristen Gill
Re: Why would no one consider Azul?
by
William Smith
Not quite sure what you mean.
People do consider Azul - it's pretty heavily used in finance, lots of low latency systems run on it, LMAX have talked publicly about switching to it for their exchange and so on.
Zing is a fantastic product, and if you need pauseless GC than it should absolutely be something you look at. However it only runs on Linux, and is also closed source, and thus can't be included as part of the OpenJDK distribution.
I think I'm right in saying it also needs some sort of virtualisation layer in order to run though I'm not sure if this is still true - it used to require a hypervisor. If anyone from Azul could comment actually that would be cool.
People do consider Azul - it's pretty heavily used in finance, lots of low latency systems run on it, LMAX have talked publicly about switching to it for their exchange and so on.
Zing is a fantastic product, and if you need pauseless GC than it should absolutely be something you look at. However it only runs on Linux, and is also closed source, and thus can't be included as part of the OpenJDK distribution.
I think I'm right in saying it also needs some sort of virtualisation layer in order to run though I'm not sure if this is still true - it used to require a hypervisor. If anyone from Azul could comment actually that would be cool.
Re: Why would no one consider Azul?
by
Evan Haxton
Hi William
I have worked at Azul for over 6 years as sales engineer. The product that you are thinking about was called Zing VE or Zing Virtual Edition. We no longer produce that product.
Zing can function INSIDE a level1 container such as KVM or VMWare, it is not required in order to function exceedingly well. Zing can run in a heap as small as 1GB to well over 1TB without any significant degradation in application performance.
The product has matured significantly since the last time that you checked it out. I would suggest that you check it out www.azulsystems.com
Thanks
-Evan
I have worked at Azul for over 6 years as sales engineer. The product that you are thinking about was called Zing VE or Zing Virtual Edition. We no longer produce that product.
Zing can function INSIDE a level1 container such as KVM or VMWare, it is not required in order to function exceedingly well. Zing can run in a heap as small as 1GB to well over 1TB without any significant degradation in application performance.
The product has matured significantly since the last time that you checked it out. I would suggest that you check it out www.azulsystems.com
Thanks
-Evan
Overhead of Garbage Collection
by
Shamal Jayakody
Garbage collection consumes computing resources in deciding which memory to free, even though the programmer may have already known this information. The penalty for the convenience of not annotating object lifetime manually in the source code is overhead, which can lead to decreased or uneven performance. A peer-reviewed paper came to the conclusion that GC needs five times the memory to compensate for this overhead and to perform as fast as explicit memory management. Interaction with memory hierarchy effects can make this overhead intolerable in circumstances that are hard to predict or to detect in routine testing. The impact on performance was also given by Apple as a reason for not adopting garbage collection in iOS despite being the most desired feature.
Overhead of Garbage Collection
by
Shamal Jayakody
Garbage collection consumes computing resources in deciding which memory to free, even though the programmer may have already known this information. The penalty for the convenience of not annotating object lifetime manually in the source code is overhead, which can lead to decreased or uneven performance. A peer-reviewed paper came to the conclusion that GC needs five times the memory to compensate for this overhead and to perform as fast as explicit memory management. Interaction with memory hierarchy effects can make this overhead intolerable in circumstances that are hard to predict or to detect in routine testing. The impact on performance was also given by Apple as a reason for not adopting garbage collection in iOS despite being the most desired feature.
Re: Why would no one consider Azul?
by
William Smith
Hi Evan,
That's very interesting - thanks for the update. What's changed that allows you to simulate the Vega loaded value barrier (LVB) instruction and "fast traps" on x86 without some form of virtulisation?
William
That's very interesting - thanks for the update. What's changed that allows you to simulate the Vega loaded value barrier (LVB) instruction and "fast traps" on x86 without some form of virtulisation?
William
