JEP 156: G1 GC: Reduce need for full GCs (original) (raw)
| Author | Jesper Wilhelmsson |
|---|---|
| Owner | Stefan Karlsson |
| Type | Feature |
| Scope | Implementation |
| Status | Closed / Delivered |
| Release | 8u40 |
| Component | hotspot / gc |
| Discussion | hotspot dash gc dash dev at openjdk dot java dot net |
| Effort | S |
| Duration | S |
| Depends | JEP 122: Remove the Permanent Generation |
| Reviewed by | Jon Masamitsu, Tony Printezis |
| Endorsed by | Mikael Vidstedt |
| Created | 2012/02/29 20:00 |
| Updated | 2015/02/26 00:02 |
| Issue | 8046146 |
Summary
Enhance G1 so that it does not rely on full GCs to perform class unloading or any other critical operations.
Description
The goal of G1 is to minimize pause times without constraining the heap size or the amount of live data. This is achieved by doing a large part of the GC work concurrently and also doing partial compaction. Avoiding doing full GCs (_i.e., stop-the-world GCs) is one of the major benefits of G1.
However, currently G1 relies on full GCs to unload classes. This causes a major issue with large applications that do redeployment or generate temporary classes via reflection. We need to implement class unloading without full GC in G1 to fix this. This project will enhance G1 to do class unloading at the end of concurrent marking cycles.
We will also investigate if there are other important features that depend on full GC that might cause similar problems for G1.
Testing
When testing this we need to remember to play around with all kinds of references to class loaders. Not just plain class loading in Java, but also JNI and reflection. Class redefinition could also exercise this code in unusual ways.
Risks and Assumptions
Implementing class unloading in G1 will present some new problem areas for which we have not yet finalized a solution. One example is the interaction between class unloading and "snapshot-at-the-beginning" (SATB). It may turn out to be more tricky than we have anticipated, making this a medium effort.
Dependences
This project is not immediately dependent on the removal of the permanent generation (JEP 122), but the implementation of class unloading in G1 will be simplified by that work, so it makes sense to wait with this project until the permanent generation is gone.