JEP 304: Garbage Collector Interface

OwnerRoman Kennke
Created2016/08/06 08:45
Updated2018/03/20 17:14
StatusClosed / Delivered
Componenthotspot / gc
Discussionhotspot dash gc dash dev at openjdk dot java dot net
Reviewed byAleksey Shipilev, Erik Helin, Erik Österlund, Mikael Vidstedt, Per Liden
Endorsed byMikael Vidstedt
Relates toJEP 318: Epsilon: A No-Op Garbage Collector


Improve the source code isolation of different garbage collectors by introducing a clean garbage collector (GC) interface.



Success Metrics


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:

  1. For GC developers, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
  2. For HotSpot developers that aren't GC developers, it is confusing where to find a particular piece of code for a given GC.
  3. 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.


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 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.


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.


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.


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.