-
JEP
-
Resolution: Delivered
-
P4
-
Roman Kennke
-
Feature
-
Open
-
Implementation
-
-
L
-
M
-
304
Summary
Improve the source code isolation of different garbage collectors by introducing a clean garbage collector (GC) interface.
Goals
- Better modularity for HotSpot internal GC code
- Make it simpler to add a new GC to HotSpot without perturbing the current code base
- Make it easier to exclude a GC from a JDK build
Non-Goals
- It is not a goal to actually add or remove a GC.
- This work will make progress towards build-time isolation of GC algorithms in HotSpot, but it is not a goal to fully achieve build-time isolation (that is for another JEP).
Success Metrics
- The implementation will be considered a success if GC implementations are mostly contained within source files in their respective
src/hotspot/share/gc/$NAME
directory and potentially thesrc/hotspot/cpu/share/gc/$NAME
directory. Minimal code outside of those directories should include files from within those directories, and there should be very few GC specificif
-else
branches. - Performance should not regress due to this refactoring.
Motivation
Each garbage collector implementation currently consists of source files inside their src/hotspot/share/gc/$NAME
directories, e.g. G1 is in src/hotspot/share/gc/g1
, CMS in src/hotspot/share/gc/cms
, etc. However, there are bits and pieces scattered all over the HotSpot sources. For example, most GCs require certain barriers, which need to be implemented in the runtime, interpreter, C1 and C2. Those barriers are not contained in the GC's specific directory, but are instead implemented in the shared interpreter, C1 and C2 source code (often guarded by long if
-else
-chains). The same problem applies to for example diagnostic code such as the MemoryMXBeans
. There are several disadvantages to this source code layout:
- For GC developers, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
- For HotSpot developers that aren't GC developers, it is confusing where to find a particular piece of code for a given GC.
- It is difficult to exclude, at build time, specific garbage collector(s). The
#define
INCLUDE_ALL_GCS
has long been a way to build the JVM with only the serial collector built-in, but this mechanism is becoming too inflexible.
A cleaner GC interface would make it much easier to implement new collectors, it would make the code much cleaner, and simpler to exclude one or several collectors at build time. Adding a new garbage collector should be a matter of implementing a well documented set of interfaces, rather than figuring out all the places in HotSpot that needs changing.
Description
The GC interface would be defined by the existing class CollectedHeap
which every garbage collector needs to implement. The CollectedHeap
class would drive most aspects of interaction between the garbage collector and the rest of HotSpot (there a few utility classes needed prior to a CollectedHeap
being instantiated). More specifically, a garbage collector implementation will have to provide:
- The heap, a subclass of
CollectedHeap
- The barrier set, a subclass of
BarrierSet
, which implements the various barriers for the runtime - An implementation of
CollectorPolicy
- An implementation of
GCInterpreterSupport
, which implements the various barriers for a GC for the interpreter (using assembler instructions) - An implementation of
GCC1Support
, which implements the various barriers for a GC for the C1 compiler - An implementation of
GCC2Support
, which implements the various barriers for a GC for the C2 compiler - Initialization of eventual GC specific arguments
- Setup of a
MemoryService
, the related memory pools, memory managers, etc.
The code for implementation details that are shared between multiple garbage collectors should exist in a helper class. This way it can easily be used by the different GC implementations. For example, there could be a helper class that implements the various barriers for card table support, and any GC that requires card table post-barriers would call the corresponding methods of that helper class. This way the interface provides flexibility to implement completely new barriers, and at the same time allows for reuse of existing code in a mix-and-match style.
Alternatives
An alternative would be to continue using the current architecture. This will most likely work for some time longer, but will hinder future development of new GC algorithms and removal of old ones.
Testing
This is purely refactoring. Everything that worked before needs to work afterwards, and performance should not regress. Running the standard regression test suites should suffice; no new tests have to be developed.
Risks and Assumptions
The risk is low, this is mainly a refactoring of HotSpot internal code. There is a risk that performance could be harmed, for example if additional virtual calls would be introduced. This risk can be mitigated by continuous performance testing.
Dependences
This JEP will help with JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector, because it provides a way to isolate it, and allow it to be maintained by others if needed.
This JEP will also help with JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector, and make its changes less intrusive.
- blocks
-
JDK-8197831 JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
- Closed
- relates to
-
JDK-8179268 Factor out AdaptiveSizePolicy from top-level interfaces CollectorPolicy and CollectedHeap
- Resolved
-
JDK-8179387 Factor out CMS specific code from GenCollectedHeap into its own subclass
- Resolved
-
JDK-8183542 Factor out serial GC specific code from GenCollectedHeap into its own subclass
- Resolved
-
JDK-8184181 Use oopDesc::cas_set_mark() instead of raw CAS when accessing oop header
- Resolved
-
JDK-8184914 Use MacroAssembler::cmpoop() consistently when comparing heap objects
- Resolved
-
JDK-8189171 Move GC argument processing into GC specific classes
- Resolved
-
JDK-8189276 Make SuspendibleThreadSet and related code available to other GCs
- Resolved
-
JDK-8189389 Move heap creation into GC interface
- Resolved
-
JDK-8191564 Refactor GC related servicability code into GC specific subclasses
- Resolved
-
JDK-8179259 Clean up BarrierSet
- Closed
-
JDK-8179260 Replace calls to G1SATBCardTableModRefBS::enqueue() with proper BarrierSet API
- Closed
-
JDK-8179261 Replace always_update_barrier_set with proper API in BarrierSet
- Closed
-
JDK-8189364 Make CMS use SuspendibleThreadSet for safepoint synchronization
- Closed
-
JDK-8189871 Refactor GC barriers to use declarative semantics
- Resolved
-
JDK-8174901 JEP 318: Epsilon: A No-Op Garbage Collector (Experimental)
- Closed