Driving factors

Imagine that you are a GC developer and you are supposed to know all the places where you could locate the code for GC in HotSpot. If this doesn't sound scary enough, imagine how it would feel if you didn't know how to extend it to your specific requirements. Or, imagine that you are a HotSpot developer (not a GC developer), and you can't seem to find a specific code for a GC. We are not done yet—now imagine that you must exclude a specific GC at build time. These cases are represented in the following diagram:

The preceding use cases demonstrate the major factors driving the changes to the code base—by pushing the creation of a clean GC interface.

Even though the code of the GCs was defined in their respective directories (for example, the src/hotspot/share/gc/g1 stored code for G1 GC), some code was defined outside these directories. A typical example of this is the barrier required by most of the GC. Since the barrier code was implemented in the C1 and C2 runtime interpreter, this code was defined in the directories that defined the code for C1 and C2. However, this leads to a fragmented GC code, which is hard to track and locate.

A GC interface introduces a layer of abstraction, taking the burden to track all the GC code off a developer (both GC and HotSpot).