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 the `src/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 specific `if`-`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:

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. 

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][1], 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][2], and make its changes less intrusive. 

[1]: http://openjdk.java.net/jeps/291
[2]: http://openjdk.java.net/jeps/189