Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8163329

JEP 304: Garbage Collector Interface

    Details

    • Type: JEP
    • Status: Integrated
    • Priority: P4
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: hotspot
    • Author:
      Roman Kennke
    • JEP Type:
      Feature
    • Exposure:
      Open
    • Subcomponent:
      gc
    • Scope:
      Implementation
    • Discussion:
      hotspot dash gc dash dev at openjdk dot java dot net
    • Effort:
      L
    • Duration:
      M
    • JEP Number:
      304

      Description

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

        Issue Links

          Activity

          rkennke Roman Kennke created issue -
          rkennke Roman Kennke made changes -
          Field Original Value New Value
          Description Summary
          -------

          Improve build-time isolation of different garbage collectors by designing a clean GC interface.

          Goals
          -----

          - Better modularity
          - Making it simpler to add a new GC to Hotspot without perturbing the current code base
          - Likewise, make it easier to exclude a GC from OpenJDK build

          Non-Goals
          ---------

          - It is not a goal to actually add or remove a GC

          Success Metrics
          ---------------

          The implementation is considered a success, if GC implementations are completely contained within source files in their src/share/vm/gc/$NAME and maybe src/cpu/share/vm/gc/$NAME directories. No code outside of those directories should include files from within those directories, nor should there be any GC-specific if-else branches. Code for one GC implementation must only depend on code in src/share/vm/gc/shared and its own subdirectory.

          Performance must not be negatively impacted.

          Motivation
          ----------

          Currently, each garbage collector implementation consists of source files inside their src/share/vm/gc/$NAME directories, e.g. G1 is in src/share/vm/gc/g1, CMS in src/share/vm/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 are not implemented by the GC that require them, but ususally in place, guarded by if-else-chains testing for specific GC implementations currently in use. Likewise, there are other small pieces of code in various places that are treated like this.

          This has several disadvantages.

          1. For GC implementors, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
          2. It is difficult to exclude, at build time, specific garbage collector(s). This has recently come up with the proposal to deprecate the CMS collector (JEP 291). Similarily, the INCLUDE_ALL_GCS has long been a way to build the JVM with only the serial collector built-in.

          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.

          Extensibility: 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 the runtime, interpreter, C1 and C2 that needs changing. A new garbage collector may require new interfaces (like for example, Shenandoah requires read- and write barriers, even for primitive type memory access). We acknowledge that there is no one GC algorithm which suits everyone's needs. Also, new memory architectures may require new/changed interfaces. The GC interfaces should allow for relatively easy extensions.

          The interface should be designed with JVMCI in mind, it should be clear to an implementation of JVMCI what to implement and how in order to support which GC(s).

          Last but not least, a clean GC interface would help tremendously with inclusion of new GCs like Shenandoah (JEP 189).


          Description
          -----------

          The idea is that the GC interface would be defined by a single class named GCInterface. Every collector needs to implement that. The GCInterface class would drive all aspects of interaction between the garbage collector and the rest of hotspot:

          - A specific instance of GCInterface would be created by a factory method (probably the only method in shared code with knowledge about specific GCs).
          The GCInterface provides:
          - 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 and AdaptiveSizePolicy
          - 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
          - VM argument initialization (what is currently scattered over arguments.cpp)
          - Eventually, we might consider moving non-heap related GC interface methods from CollectedHeap to GCInterface.
          - Setup of MemoryService, the related memory pools, memory managers, etc.
          - Safepointing the GC thread(s) should reuse SuspendibleThreadSet if possible/feasible.
          - Code (in the runtime, interpreter, C1 and C2) that currently has if-else switches to do GC specific things need to be changed to call the corresponding GCInterface

          During JIT and interpreter compilation, the barriers for the interpreter and C1 and C2 compilers would be generated by the GC, through a virtual call, e.g. oopDesc::bs()->c1_support()->pre_barrier(...).

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implemenations that need it. 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 CardTable 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. It needs to be determined yet on where such helper code should be kept. E.g. for C2-specific barrier code, should it be in src/share/vm/gc/shared or src/share/vm/opto or maybe some subdirectory-combination like src/share/vm/gc/shared/c2 ? Or even a separate directory altogether?


          ### Example

          To give one example to illustrate the approach I'd like to take for the GC interface. It came out of an earlier discussion I had with Jon:

          klass_oop_store() in klass.cpp

              void Klass::klass_oop_store(oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                // do the store
                if (always_do_update_barrier) {
                  klass_oop_store((volatile oop*)p, v);
                } else {
                  klass_update_barrier_set_pre(p, v);
                  *p = v;
                  klass_update_barrier_set(v);
                }
              }
               
              void Klass::klass_oop_store(volatile oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                klass_update_barrier_set_pre((oop*)p, v); // Cast away volatile.
                OrderAccess::release_store_ptr(p, v);
                klass_update_barrier_set(v);
              }

          "always_do_update_barrier" is only going to be true for
          CMS currently.

          With the GCInterface there would be a call into GC specific code that
          would do the actual store? Something like

              void Klass::klass_oop_store(oop* p, oop v) {
                // The following should actually be done statically once, somewhere else.
                // It's only here to demonstrate the mechanics of the GC interface.
                GCInterface* gci = GCInterface::get_interface();
                BarrierSet* bs = gci->barrier_set();
                bs->oop_store(p, v);
              }

          For GC's that need the memory barrier

              GCBarrierSet::_oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                OrderAccess::release_store_ptr(p, v);
                post_barrier(p, v); // Non-virtual
              }

          Otherwise

              GCBarrierSet::oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                *p = v;
                post_barrier(p, v); // Non-virtual
              }

          This way we'd reduce the number of virtual calls to 1. Plus, GCs that don't actually need a pre- or post-barrier (e.g. Shenandoah doesn't require post-barriers) can leave them out altogether. And as an aside, the above interface would actually belong into BarrierSet, and thus get called through the cached BarrierSet instance as for the current pre-barrier and post-barrier calls.

          And since oop_store() in oop.inline.hpp basically does the same, it could reuse the exact same GC interface.


          Alternatives
          ------------

          The current GC interface consists of:

          - CollectorPolicy
          - BarrierSet
          - CollectedHeap

          We could work from there, and extend them to achieve separation. However, it has several problems:

          - CollectedHeap is already very big and loaded with functionality that doesn't really concern the heap.
          - BarrierSet provides a good basis, but needs cleanup (remove unused stuff) and extensions for C1, C2 and interpreter.

          I am leaning to make a new GCInterface, that would be implemented by each GC, and provides a CollectorPolicy, CollectedHeap and BarrierSet, plus any new GC interface related things that are needed (e.g. GCServicabilitySupport, etc).

          Testing
          -------

          This is purely refactoring. Everything that worked before needs to work afterwards.

          Risks and Assumptions
          ---------------------

          A GC interface adds complexity. Currently stable & tested code in all collectors need to be changed. We hope that the benefit of clean and strict interface between GCs and the rest of Hotspot outweights the cost and risk of changes.

          We may not be able to implement it without harming performance.

          A first prototype would be implemented by turning off INCLUDE_ALL_GCS and only target the serial collector. This will allow us to identify obvious problems early on and address them.
          I suggest to integrate the majority of changes required for the GC interface at once, in order to get a fairly uniform treatment of all cases. Interpreter, C1 and C2 could be addressed in additional steps.


          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 keep it maintained by the OpenJDK community 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. The GCInterface needs to be extended to account for Shenandoah's read- and write-barriers though. Shenandoah requires read- and write-barriers in BarrierSet (for each of: runtime, interpreter, c1 and c2) plus the corresponding hooks all over the runtime, interpreter, c1 and c2. This change is very significant and would need to be discussed as part of the Shenandoah JEP. We added methods read_barrier() and write_barrier() and obj_equals() to BarrierSet, as well as all the corresponding hooks in the runtime, plus equivalent code generation in the interpreter, C1 and C2.


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

          Improve build-time isolation of different garbage collectors by designing a clean GC interface.

          Goals
          -----

          - Better modularity
          - Making it simpler to add a new GC to Hotspot without perturbing the current code base
          - Likewise, make it easier to exclude a GC from OpenJDK build

          Non-Goals
          ---------

          - It is not a goal to actually add or remove a GC

          Success Metrics
          ---------------

          The implementation is considered a success, if GC implementations are completely contained within source files in their src/share/vm/gc/$NAME and maybe src/cpu/share/vm/gc/$NAME directories. No code outside of those directories should include files from within those directories, nor should there be any GC-specific if-else branches. Code for one GC implementation must only depend on code in src/share/vm/gc/shared and its own subdirectory.

          Performance must not be negatively impacted.

          Motivation
          ----------

          Currently, each garbage collector implementation consists of source files inside their src/share/vm/gc/$NAME directories, e.g. G1 is in src/share/vm/gc/g1, CMS in src/share/vm/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 are not implemented by the GC that require them, but ususally in place, guarded by if-else-chains testing for specific GC implementations currently in use. Likewise, there are other small pieces of code in various places that are treated like this.

          This has several disadvantages.

          1. For GC implementors, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
          2. It is difficult to exclude, at build time, specific garbage collector(s). This has recently come up with the proposal to deprecate the CMS collector (JEP 291). Similarily, the INCLUDE_ALL_GCS has long been a way to build the JVM with only the serial collector built-in.

          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.

          Extensibility: 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 the runtime, interpreter, C1 and C2 that needs changing. A new garbage collector may require new interfaces (like for example, Shenandoah requires read- and write barriers, even for primitive type memory access). We acknowledge that there is no one GC algorithm which suits everyone's needs. Also, new memory architectures may require new/changed interfaces. The GC interfaces should allow for relatively easy extensions.

          The interface should be designed with JVMCI in mind, it should be clear to an implementation of JVMCI what to implement and how in order to support which GC(s).

          Last but not least, a clean GC interface would help tremendously with inclusion of new GCs like Shenandoah (JEP 189).


          Description
          -----------

          The idea is that the GC interface would be defined by a single class named GCInterface. Every collector needs to implement that. The GCInterface class would drive all aspects of interaction between the garbage collector and the rest of hotspot:

          - A specific instance of GCInterface would be created by a factory method (probably the only method in shared code with knowledge about specific GCs).
          The GCInterface provides:
          - 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 and AdaptiveSizePolicy
          - 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
          - VM argument initialization (what is currently scattered over arguments.cpp)
          - Eventually, we might consider moving non-heap related GC interface methods from CollectedHeap to GCInterface.
          - Setup of MemoryService, the related memory pools, memory managers, etc.
          - Safepointing the GC thread(s) should reuse SuspendibleThreadSet if possible/feasible.
          - Code (in the runtime, interpreter, C1 and C2) that currently has if-else switches to do GC specific things need to be changed to call the corresponding GCInterface

          During JIT and interpreter compilation, the barriers for the interpreter and C1 and C2 compilers would be generated by the GC, through a virtual call, e.g. oopDesc::bs()->c1_support()->pre_barrier(...).

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implemenations that need it. 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 CardTable 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. It needs to be determined yet on where such helper code should be kept. E.g. for C2-specific barrier code, should it be in src/share/vm/gc/shared or src/share/vm/opto or maybe some subdirectory-combination like src/share/vm/gc/shared/c2 ? Or even a separate directory altogether?


          ### Example

          To give one example to illustrate the approach I'd like to take for the GC interface. It came out of an earlier discussion I had with Jon:

          klass_oop_store() in klass.cpp

              void Klass::klass_oop_store(oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                // do the store
                if (always_do_update_barrier) {
                  klass_oop_store((volatile oop*)p, v);
                } else {
                  klass_update_barrier_set_pre(p, v);
                  *p = v;
                  klass_update_barrier_set(v);
                }
              }
               
              void Klass::klass_oop_store(volatile oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                klass_update_barrier_set_pre((oop*)p, v); // Cast away volatile.
                OrderAccess::release_store_ptr(p, v);
                klass_update_barrier_set(v);
              }

          "always_do_update_barrier" is only going to be true for
          CMS currently.

          With the GCInterface there would be a call into GC specific code that
          would do the actual store? Something like

              void Klass::klass_oop_store(oop* p, oop v) {
                // The following should actually be done statically once, somewhere else.
                // It's only here to demonstrate the mechanics of the GC interface.
                GCInterface* gci = GCInterface::get_interface();
                BarrierSet* bs = gci->barrier_set();
                bs->oop_store(p, v);
              }

          For GC's that need the memory barrier

              GCBarrierSet::_oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                OrderAccess::release_store_ptr(p, v);
                post_barrier(p, v); // Non-virtual
              }

          Otherwise

              GCBarrierSet::oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                *p = v;
                post_barrier(p, v); // Non-virtual
              }

          This way we'd reduce the number of virtual calls to 1. Plus, GCs that don't actually need a pre- or post-barrier (e.g. Shenandoah doesn't require post-barriers) can leave them out altogether. And as an aside, the above interface would actually belong into BarrierSet, and thus get called through the cached BarrierSet instance as for the current pre-barrier and post-barrier calls.

          And since oop_store() in oop.inline.hpp basically does the same, it could reuse the exact same GC interface.


          Alternatives
          ------------

          The current GC interface consists of:

          - CollectorPolicy
          - BarrierSet
          - CollectedHeap

          We could work from there, and extend them to achieve separation. However, it has several problems:

          - CollectedHeap is already very big and loaded with functionality that doesn't really concern the heap.
          - BarrierSet provides a good basis, but needs cleanup (remove unused stuff) and extensions for C1, C2 and interpreter.

          I am leaning to make a new GCInterface, that would be implemented by each GC, and provides a CollectorPolicy, CollectedHeap and BarrierSet, plus any new GC interface related things that are needed (e.g. GCServicabilitySupport, etc).

          Testing
          -------

          This is purely refactoring. Everything that worked before needs to work afterwards.

          Risks and Assumptions
          ---------------------

          A GC interface adds complexity. Currently stable & tested code in all collectors need to be changed. We hope that the benefit of clean and strict interface between GCs and the rest of Hotspot outweights the cost and risk of changes.

          We may not be able to implement it without harming performance.

          A first prototype would be implemented by focusing on code that directly includes gc/cms files, and abstract that out into GC interface code. This will allow us to identify obvious problems early on and address them.
          I suggest to integrate the majority of changes required for the GC interface at once, in order to get a fairly uniform treatment of all cases. Interpreter, C1 and C2 could be addressed in additional steps.


          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 keep it maintained by the OpenJDK community 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. The GCInterface needs to be extended to account for Shenandoah's read- and write-barriers though. Shenandoah requires read- and write-barriers in BarrierSet (for each of: runtime, interpreter, c1 and c2) plus the corresponding hooks all over the runtime, interpreter, c1 and c2. This change is very significant and would need to be discussed as part of the Shenandoah JEP. We added methods read_barrier() and write_barrier() and obj_equals() to BarrierSet, as well as all the corresponding hooks in the runtime, plus equivalent code generation in the interpreter, C1 and C2.


          - [1] http://openjdk.java.net/jeps/291
          - [2] http://openjdk.java.net/jeps/189
          rkennke Roman Kennke made changes -
          Description Summary
          -------

          Improve build-time isolation of different garbage collectors by designing a clean GC interface.

          Goals
          -----

          - Better modularity
          - Making it simpler to add a new GC to Hotspot without perturbing the current code base
          - Likewise, make it easier to exclude a GC from OpenJDK build

          Non-Goals
          ---------

          - It is not a goal to actually add or remove a GC

          Success Metrics
          ---------------

          The implementation is considered a success, if GC implementations are completely contained within source files in their src/share/vm/gc/$NAME and maybe src/cpu/share/vm/gc/$NAME directories. No code outside of those directories should include files from within those directories, nor should there be any GC-specific if-else branches. Code for one GC implementation must only depend on code in src/share/vm/gc/shared and its own subdirectory.

          Performance must not be negatively impacted.

          Motivation
          ----------

          Currently, each garbage collector implementation consists of source files inside their src/share/vm/gc/$NAME directories, e.g. G1 is in src/share/vm/gc/g1, CMS in src/share/vm/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 are not implemented by the GC that require them, but ususally in place, guarded by if-else-chains testing for specific GC implementations currently in use. Likewise, there are other small pieces of code in various places that are treated like this.

          This has several disadvantages.

          1. For GC implementors, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
          2. It is difficult to exclude, at build time, specific garbage collector(s). This has recently come up with the proposal to deprecate the CMS collector (JEP 291). Similarily, the INCLUDE_ALL_GCS has long been a way to build the JVM with only the serial collector built-in.

          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.

          Extensibility: 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 the runtime, interpreter, C1 and C2 that needs changing. A new garbage collector may require new interfaces (like for example, Shenandoah requires read- and write barriers, even for primitive type memory access). We acknowledge that there is no one GC algorithm which suits everyone's needs. Also, new memory architectures may require new/changed interfaces. The GC interfaces should allow for relatively easy extensions.

          The interface should be designed with JVMCI in mind, it should be clear to an implementation of JVMCI what to implement and how in order to support which GC(s).

          Last but not least, a clean GC interface would help tremendously with inclusion of new GCs like Shenandoah (JEP 189).


          Description
          -----------

          The idea is that the GC interface would be defined by a single class named GCInterface. Every collector needs to implement that. The GCInterface class would drive all aspects of interaction between the garbage collector and the rest of hotspot:

          - A specific instance of GCInterface would be created by a factory method (probably the only method in shared code with knowledge about specific GCs).
          The GCInterface provides:
          - 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 and AdaptiveSizePolicy
          - 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
          - VM argument initialization (what is currently scattered over arguments.cpp)
          - Eventually, we might consider moving non-heap related GC interface methods from CollectedHeap to GCInterface.
          - Setup of MemoryService, the related memory pools, memory managers, etc.
          - Safepointing the GC thread(s) should reuse SuspendibleThreadSet if possible/feasible.
          - Code (in the runtime, interpreter, C1 and C2) that currently has if-else switches to do GC specific things need to be changed to call the corresponding GCInterface

          During JIT and interpreter compilation, the barriers for the interpreter and C1 and C2 compilers would be generated by the GC, through a virtual call, e.g. oopDesc::bs()->c1_support()->pre_barrier(...).

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implemenations that need it. 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 CardTable 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. It needs to be determined yet on where such helper code should be kept. E.g. for C2-specific barrier code, should it be in src/share/vm/gc/shared or src/share/vm/opto or maybe some subdirectory-combination like src/share/vm/gc/shared/c2 ? Or even a separate directory altogether?


          ### Example

          To give one example to illustrate the approach I'd like to take for the GC interface. It came out of an earlier discussion I had with Jon:

          klass_oop_store() in klass.cpp

              void Klass::klass_oop_store(oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                // do the store
                if (always_do_update_barrier) {
                  klass_oop_store((volatile oop*)p, v);
                } else {
                  klass_update_barrier_set_pre(p, v);
                  *p = v;
                  klass_update_barrier_set(v);
                }
              }
               
              void Klass::klass_oop_store(volatile oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                klass_update_barrier_set_pre((oop*)p, v); // Cast away volatile.
                OrderAccess::release_store_ptr(p, v);
                klass_update_barrier_set(v);
              }

          "always_do_update_barrier" is only going to be true for
          CMS currently.

          With the GCInterface there would be a call into GC specific code that
          would do the actual store? Something like

              void Klass::klass_oop_store(oop* p, oop v) {
                // The following should actually be done statically once, somewhere else.
                // It's only here to demonstrate the mechanics of the GC interface.
                GCInterface* gci = GCInterface::get_interface();
                BarrierSet* bs = gci->barrier_set();
                bs->oop_store(p, v);
              }

          For GC's that need the memory barrier

              GCBarrierSet::_oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                OrderAccess::release_store_ptr(p, v);
                post_barrier(p, v); // Non-virtual
              }

          Otherwise

              GCBarrierSet::oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                *p = v;
                post_barrier(p, v); // Non-virtual
              }

          This way we'd reduce the number of virtual calls to 1. Plus, GCs that don't actually need a pre- or post-barrier (e.g. Shenandoah doesn't require post-barriers) can leave them out altogether. And as an aside, the above interface would actually belong into BarrierSet, and thus get called through the cached BarrierSet instance as for the current pre-barrier and post-barrier calls.

          And since oop_store() in oop.inline.hpp basically does the same, it could reuse the exact same GC interface.


          Alternatives
          ------------

          The current GC interface consists of:

          - CollectorPolicy
          - BarrierSet
          - CollectedHeap

          We could work from there, and extend them to achieve separation. However, it has several problems:

          - CollectedHeap is already very big and loaded with functionality that doesn't really concern the heap.
          - BarrierSet provides a good basis, but needs cleanup (remove unused stuff) and extensions for C1, C2 and interpreter.

          I am leaning to make a new GCInterface, that would be implemented by each GC, and provides a CollectorPolicy, CollectedHeap and BarrierSet, plus any new GC interface related things that are needed (e.g. GCServicabilitySupport, etc).

          Testing
          -------

          This is purely refactoring. Everything that worked before needs to work afterwards.

          Risks and Assumptions
          ---------------------

          A GC interface adds complexity. Currently stable & tested code in all collectors need to be changed. We hope that the benefit of clean and strict interface between GCs and the rest of Hotspot outweights the cost and risk of changes.

          We may not be able to implement it without harming performance.

          A first prototype would be implemented by focusing on code that directly includes gc/cms files, and abstract that out into GC interface code. This will allow us to identify obvious problems early on and address them.
          I suggest to integrate the majority of changes required for the GC interface at once, in order to get a fairly uniform treatment of all cases. Interpreter, C1 and C2 could be addressed in additional steps.


          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 keep it maintained by the OpenJDK community 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. The GCInterface needs to be extended to account for Shenandoah's read- and write-barriers though. Shenandoah requires read- and write-barriers in BarrierSet (for each of: runtime, interpreter, c1 and c2) plus the corresponding hooks all over the runtime, interpreter, c1 and c2. This change is very significant and would need to be discussed as part of the Shenandoah JEP. We added methods read_barrier() and write_barrier() and obj_equals() to BarrierSet, as well as all the corresponding hooks in the runtime, plus equivalent code generation in the interpreter, C1 and C2.


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

          Improve build-time isolation of different garbage collectors by designing a clean GC interface.

          Goals
          -----

          - Better modularity
          - Making it simpler to add a new GC to Hotspot without perturbing the current code base
          - Likewise, make it easier to exclude a GC from OpenJDK build

          Non-Goals
          ---------

          - It is not a goal to actually add or remove a GC

          Success Metrics
          ---------------

          The implementation is considered a success, if GC implementations are completely contained within source files in their src/share/vm/gc/$NAME and maybe src/cpu/share/vm/gc/$NAME directories. No code outside of those directories should include files from within those directories, nor should there be any GC-specific if-else branches. Code for one GC implementation must only depend on code in src/share/vm/gc/shared and its own subdirectory.

          Performance must not be negatively impacted.

          Motivation
          ----------

          Currently, each garbage collector implementation consists of source files inside their src/share/vm/gc/$NAME directories, e.g. G1 is in src/share/vm/gc/g1, CMS in src/share/vm/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 are not implemented by the GC that require them, but ususally in place, guarded by if-else-chains testing for specific GC implementations currently in use. Likewise, there are other small pieces of code in various places that are treated like this.

          This has several disadvantages.

          1. For GC implementors, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
          2. It is difficult to exclude, at build time, specific garbage collector(s). This has recently come up with the proposal to deprecate the CMS collector (JEP 291). Similarily, the INCLUDE_ALL_GCS has long been a way to build the JVM with only the serial collector built-in.

          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.

          Extensibility: 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 the runtime, interpreter, C1 and C2 that needs changing. A new garbage collector may require new interfaces (like for example, Shenandoah requires read- and write barriers, even for primitive type memory access). We acknowledge that there is no one GC algorithm which suits everyone's needs. Also, new memory architectures may require new/changed interfaces. The GC interfaces should allow for relatively easy extensions.

          The interface should be designed with JVMCI in mind, it should be clear to an implementation of JVMCI what to implement and how in order to support which GC(s).

          Last but not least, a clean GC interface would help tremendously with inclusion of new GCs like Shenandoah (JEP 189).


          Description
          -----------

          The idea is that the GC interface would be defined by a single class named GCInterface. Every collector needs to implement that. The GCInterface class would drive all aspects of interaction between the garbage collector and the rest of hotspot:

          - A specific instance of GCInterface would be created by a factory method (probably the only method in shared code with knowledge about specific GCs).
          The GCInterface provides:
          - 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 and AdaptiveSizePolicy
          - 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
          - VM argument initialization (what is currently scattered over arguments.cpp)
          - Eventually, we might consider moving non-heap related GC interface methods from CollectedHeap to GCInterface.
          - Setup of MemoryService, the related memory pools, memory managers, etc.
          - Safepointing the GC thread(s) should reuse SuspendibleThreadSet if possible/feasible.
          - Code (in the runtime, interpreter, C1 and C2) that currently has if-else switches to do GC specific things need to be changed to call the corresponding GCInterface

          During JIT and interpreter compilation, the barriers for the interpreter and C1 and C2 compilers would be generated by the GC, through a virtual call, e.g. oopDesc::bs()->c1_support()->pre_barrier(...).

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implemenations that need it. 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 CardTable 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. It needs to be determined yet on where such helper code should be kept. E.g. for C2-specific barrier code, should it be in src/share/vm/gc/shared or src/share/vm/opto or maybe some subdirectory-combination like src/share/vm/gc/shared/c2 ? Or even a separate directory altogether?


          ### Example

          To give one example to illustrate the approach I'd like to take for the GC interface. It came out of an earlier discussion I had with Jon:

          klass_oop_store() in klass.cpp

              void Klass::klass_oop_store(oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                // do the store
                if (always_do_update_barrier) {
                  klass_oop_store((volatile oop*)p, v);
                } else {
                  klass_update_barrier_set_pre(p, v);
                  *p = v;
                  klass_update_barrier_set(v);
                }
              }
               
              void Klass::klass_oop_store(volatile oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                klass_update_barrier_set_pre((oop*)p, v); // Cast away volatile.
                OrderAccess::release_store_ptr(p, v);
                klass_update_barrier_set(v);
              }

          "always_do_update_barrier" is only going to be true for
          CMS currently.

          With the GCInterface there would be a call into GC specific code that
          would do the actual store? Something like

              void Klass::klass_oop_store(oop* p, oop v) {
                // The following should actually be done statically once, somewhere else.
                // It's only here to demonstrate the mechanics of the GC interface.
                GCInterface* gci = GCInterface::get_interface();
                BarrierSet* bs = gci->barrier_set();
                bs->oop_store(p, v);
              }

          For GC's that need the memory barrier

              GCBarrierSet::_oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                OrderAccess::release_store_ptr(p, v);
                post_barrier(p, v); // Non-virtual
              }

          Otherwise

              GCBarrierSet::oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                *p = v;
                post_barrier(p, v); // Non-virtual
              }

          This way we'd reduce the number of virtual calls to 1. Plus, GCs that don't actually need a pre- or post-barrier (e.g. Shenandoah doesn't require post-barriers) can leave them out altogether. And as an aside, the above interface would actually belong into BarrierSet, and thus get called through the cached BarrierSet instance as for the current pre-barrier and post-barrier calls.

          And since oop_store() in oop.inline.hpp basically does the same, it could reuse the exact same GC interface.


          Alternatives
          ------------

          The current GC interface consists of:

          - CollectorPolicy
          - BarrierSet
          - CollectedHeap

          We could work from there, and extend them to achieve separation. However, it has several problems:

          - CollectedHeap is already very big and loaded with functionality that doesn't really concern the heap.
          - BarrierSet provides a good basis, but needs cleanup (remove unused stuff) and extensions for C1, C2 and interpreter.

          I am leaning to make a new GCInterface, that would be implemented by each GC, and provides a CollectorPolicy, CollectedHeap and BarrierSet, plus any new GC interface related things that are needed (e.g. GCServicabilitySupport, etc).

          Testing
          -------

          This is purely refactoring. Everything that worked before needs to work afterwards.

          Risks and Assumptions
          ---------------------

          A GC interface adds complexity. Currently stable & tested code in all collectors need to be changed. We hope that the benefit of clean and strict interface between GCs and the rest of Hotspot outweights the cost and risk of changes.

          We may not be able to implement it without harming performance.

          A first prototype would be implemented by focusing on code that directly includes gc/cms files, and abstract that out into GC interface code. This will allow us to identify obvious problems early on and address them.
          I suggest to integrate the majority of changes required for the GC interface at once, in order to get a fairly uniform treatment of all cases. Interpreter, C1 and C2 could be addressed in additional steps.

          A current snapshot of my work-in-progress can be found here: http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.00/


          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 keep it maintained by the OpenJDK community 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. The GCInterface needs to be extended to account for Shenandoah's read- and write-barriers though. Shenandoah requires read- and write-barriers in BarrierSet (for each of: runtime, interpreter, c1 and c2) plus the corresponding hooks all over the runtime, interpreter, c1 and c2. This change is very significant and would need to be discussed as part of the Shenandoah JEP. We added methods read_barrier() and write_barrier() and obj_equals() to BarrierSet, as well as all the corresponding hooks in the runtime, plus equivalent code generation in the interpreter, C1 and C2.


          - [1] http://openjdk.java.net/jeps/291
          - [2] http://openjdk.java.net/jeps/189
          rkennke Roman Kennke made changes -
          Description Summary
          -------

          Improve build-time isolation of different garbage collectors by designing a clean GC interface.

          Goals
          -----

          - Better modularity
          - Making it simpler to add a new GC to Hotspot without perturbing the current code base
          - Likewise, make it easier to exclude a GC from OpenJDK build

          Non-Goals
          ---------

          - It is not a goal to actually add or remove a GC

          Success Metrics
          ---------------

          The implementation is considered a success, if GC implementations are completely contained within source files in their src/share/vm/gc/$NAME and maybe src/cpu/share/vm/gc/$NAME directories. No code outside of those directories should include files from within those directories, nor should there be any GC-specific if-else branches. Code for one GC implementation must only depend on code in src/share/vm/gc/shared and its own subdirectory.

          Performance must not be negatively impacted.

          Motivation
          ----------

          Currently, each garbage collector implementation consists of source files inside their src/share/vm/gc/$NAME directories, e.g. G1 is in src/share/vm/gc/g1, CMS in src/share/vm/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 are not implemented by the GC that require them, but ususally in place, guarded by if-else-chains testing for specific GC implementations currently in use. Likewise, there are other small pieces of code in various places that are treated like this.

          This has several disadvantages.

          1. For GC implementors, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
          2. It is difficult to exclude, at build time, specific garbage collector(s). This has recently come up with the proposal to deprecate the CMS collector (JEP 291). Similarily, the INCLUDE_ALL_GCS has long been a way to build the JVM with only the serial collector built-in.

          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.

          Extensibility: 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 the runtime, interpreter, C1 and C2 that needs changing. A new garbage collector may require new interfaces (like for example, Shenandoah requires read- and write barriers, even for primitive type memory access). We acknowledge that there is no one GC algorithm which suits everyone's needs. Also, new memory architectures may require new/changed interfaces. The GC interfaces should allow for relatively easy extensions.

          The interface should be designed with JVMCI in mind, it should be clear to an implementation of JVMCI what to implement and how in order to support which GC(s).

          Last but not least, a clean GC interface would help tremendously with inclusion of new GCs like Shenandoah (JEP 189).


          Description
          -----------

          The idea is that the GC interface would be defined by a single class named GCInterface. Every collector needs to implement that. The GCInterface class would drive all aspects of interaction between the garbage collector and the rest of hotspot:

          - A specific instance of GCInterface would be created by a factory method (probably the only method in shared code with knowledge about specific GCs).
          The GCInterface provides:
          - 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 and AdaptiveSizePolicy
          - 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
          - VM argument initialization (what is currently scattered over arguments.cpp)
          - Eventually, we might consider moving non-heap related GC interface methods from CollectedHeap to GCInterface.
          - Setup of MemoryService, the related memory pools, memory managers, etc.
          - Safepointing the GC thread(s) should reuse SuspendibleThreadSet if possible/feasible.
          - Code (in the runtime, interpreter, C1 and C2) that currently has if-else switches to do GC specific things need to be changed to call the corresponding GCInterface

          During JIT and interpreter compilation, the barriers for the interpreter and C1 and C2 compilers would be generated by the GC, through a virtual call, e.g. oopDesc::bs()->c1_support()->pre_barrier(...).

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implemenations that need it. 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 CardTable 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. It needs to be determined yet on where such helper code should be kept. E.g. for C2-specific barrier code, should it be in src/share/vm/gc/shared or src/share/vm/opto or maybe some subdirectory-combination like src/share/vm/gc/shared/c2 ? Or even a separate directory altogether?


          ### Example

          To give one example to illustrate the approach I'd like to take for the GC interface. It came out of an earlier discussion I had with Jon:

          klass_oop_store() in klass.cpp

              void Klass::klass_oop_store(oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                // do the store
                if (always_do_update_barrier) {
                  klass_oop_store((volatile oop*)p, v);
                } else {
                  klass_update_barrier_set_pre(p, v);
                  *p = v;
                  klass_update_barrier_set(v);
                }
              }
               
              void Klass::klass_oop_store(volatile oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                klass_update_barrier_set_pre((oop*)p, v); // Cast away volatile.
                OrderAccess::release_store_ptr(p, v);
                klass_update_barrier_set(v);
              }

          "always_do_update_barrier" is only going to be true for
          CMS currently.

          With the GCInterface there would be a call into GC specific code that
          would do the actual store? Something like

              void Klass::klass_oop_store(oop* p, oop v) {
                // The following should actually be done statically once, somewhere else.
                // It's only here to demonstrate the mechanics of the GC interface.
                GCInterface* gci = GCInterface::get_interface();
                BarrierSet* bs = gci->barrier_set();
                bs->oop_store(p, v);
              }

          For GC's that need the memory barrier

              GCBarrierSet::_oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                OrderAccess::release_store_ptr(p, v);
                post_barrier(p, v); // Non-virtual
              }

          Otherwise

              GCBarrierSet::oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                *p = v;
                post_barrier(p, v); // Non-virtual
              }

          This way we'd reduce the number of virtual calls to 1. Plus, GCs that don't actually need a pre- or post-barrier (e.g. Shenandoah doesn't require post-barriers) can leave them out altogether. And as an aside, the above interface would actually belong into BarrierSet, and thus get called through the cached BarrierSet instance as for the current pre-barrier and post-barrier calls.

          And since oop_store() in oop.inline.hpp basically does the same, it could reuse the exact same GC interface.


          Alternatives
          ------------

          The current GC interface consists of:

          - CollectorPolicy
          - BarrierSet
          - CollectedHeap

          We could work from there, and extend them to achieve separation. However, it has several problems:

          - CollectedHeap is already very big and loaded with functionality that doesn't really concern the heap.
          - BarrierSet provides a good basis, but needs cleanup (remove unused stuff) and extensions for C1, C2 and interpreter.

          I am leaning to make a new GCInterface, that would be implemented by each GC, and provides a CollectorPolicy, CollectedHeap and BarrierSet, plus any new GC interface related things that are needed (e.g. GCServicabilitySupport, etc).

          Testing
          -------

          This is purely refactoring. Everything that worked before needs to work afterwards.

          Risks and Assumptions
          ---------------------

          A GC interface adds complexity. Currently stable & tested code in all collectors need to be changed. We hope that the benefit of clean and strict interface between GCs and the rest of Hotspot outweights the cost and risk of changes.

          We may not be able to implement it without harming performance.

          A first prototype would be implemented by focusing on code that directly includes gc/cms files, and abstract that out into GC interface code. This will allow us to identify obvious problems early on and address them.
          I suggest to integrate the majority of changes required for the GC interface at once, in order to get a fairly uniform treatment of all cases. Interpreter, C1 and C2 could be addressed in additional steps.

          A current snapshot of my work-in-progress can be found here: http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.00/


          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 keep it maintained by the OpenJDK community 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. The GCInterface needs to be extended to account for Shenandoah's read- and write-barriers though. Shenandoah requires read- and write-barriers in BarrierSet (for each of: runtime, interpreter, c1 and c2) plus the corresponding hooks all over the runtime, interpreter, c1 and c2. This change is very significant and would need to be discussed as part of the Shenandoah JEP. We added methods read_barrier() and write_barrier() and obj_equals() to BarrierSet, as well as all the corresponding hooks in the runtime, plus equivalent code generation in the interpreter, C1 and C2.


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

          Improve build-time isolation of different garbage collectors by designing a clean GC interface.

          Goals
          -----

          - Better modularity
          - Making it simpler to add a new GC to Hotspot without perturbing the current code base
          - Likewise, make it easier to exclude a GC from OpenJDK build

          Non-Goals
          ---------

          - It is not a goal to actually add or remove a GC

          Success Metrics
          ---------------

          The implementation is considered a success, if GC implementations are completely contained within source files in their src/share/vm/gc/$NAME and maybe src/cpu/share/vm/gc/$NAME directories. No code outside of those directories should include files from within those directories, nor should there be any GC-specific if-else branches. Code for one GC implementation must only depend on code in src/share/vm/gc/shared and its own subdirectory.

          Performance must not be negatively impacted.

          Motivation
          ----------

          Currently, each garbage collector implementation consists of source files inside their src/share/vm/gc/$NAME directories, e.g. G1 is in src/share/vm/gc/g1, CMS in src/share/vm/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 are not implemented by the GC that require them, but ususally in place, guarded by if-else-chains testing for specific GC implementations currently in use. Likewise, there are other small pieces of code in various places that are treated like this.

          This has several disadvantages.

          1. For GC implementors, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
          2. It is difficult to exclude, at build time, specific garbage collector(s). This has recently come up with the proposal to deprecate the CMS collector (JEP 291). Similarily, the INCLUDE_ALL_GCS has long been a way to build the JVM with only the serial collector built-in.

          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.

          Extensibility: 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 the runtime, interpreter, C1 and C2 that needs changing. A new garbage collector may require new interfaces (like for example, Shenandoah requires read- and write barriers, even for primitive type memory access). We acknowledge that there is no one GC algorithm which suits everyone's needs. Also, new memory architectures may require new/changed interfaces. The GC interfaces should allow for relatively easy extensions.

          The interface should be designed with JVMCI in mind, it should be clear to an implementation of JVMCI what to implement and how in order to support which GC(s).

          Last but not least, a clean GC interface would help tremendously with inclusion of new GCs like Shenandoah (JEP 189).


          Description
          -----------

          The idea is that the GC interface would be defined by a single class named GCInterface. Every collector needs to implement that. The GCInterface class would drive all aspects of interaction between the garbage collector and the rest of hotspot:

          - A specific instance of GCInterface would be created by a factory method (probably the only method in shared code with knowledge about specific GCs).
          The GCInterface provides:
          - 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 and AdaptiveSizePolicy
          - 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
          - VM argument initialization (what is currently scattered over arguments.cpp)
          - Eventually, we might consider moving non-heap related GC interface methods from CollectedHeap to GCInterface.
          - Setup of MemoryService, the related memory pools, memory managers, etc.
          - Safepointing the GC thread(s) should reuse SuspendibleThreadSet if possible/feasible.
          - Code (in the runtime, interpreter, C1 and C2) that currently has if-else switches to do GC specific things need to be changed to call the corresponding GCInterface

          During JIT and interpreter compilation, the barriers for the interpreter and C1 and C2 compilers would be generated by the GC, through a virtual call, e.g. oopDesc::bs()->c1_support()->pre_barrier(...).

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implemenations that need it. 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 CardTable 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. It needs to be determined yet on where such helper code should be kept. E.g. for C2-specific barrier code, should it be in src/share/vm/gc/shared or src/share/vm/opto or maybe some subdirectory-combination like src/share/vm/gc/shared/c2 ? Or even a separate directory altogether?


          ### Example

          To give one example to illustrate the approach I'd like to take for the GC interface. It came out of an earlier discussion I had with Jon:

          klass_oop_store() in klass.cpp

              void Klass::klass_oop_store(oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                // do the store
                if (always_do_update_barrier) {
                  klass_oop_store((volatile oop*)p, v);
                } else {
                  klass_update_barrier_set_pre(p, v);
                  *p = v;
                  klass_update_barrier_set(v);
                }
              }
               
              void Klass::klass_oop_store(volatile oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                klass_update_barrier_set_pre((oop*)p, v); // Cast away volatile.
                OrderAccess::release_store_ptr(p, v);
                klass_update_barrier_set(v);
              }

          "always_do_update_barrier" is only going to be true for
          CMS currently.

          With the GCInterface there would be a call into GC specific code that
          would do the actual store? Something like

              void Klass::klass_oop_store(oop* p, oop v) {
                // The following should actually be done statically once, somewhere else.
                // It's only here to demonstrate the mechanics of the GC interface.
                GCInterface* gci = GCInterface::get_interface();
                BarrierSet* bs = gci->barrier_set();
                bs->oop_store(p, v);
              }

          For GC's that need the memory barrier

              GCBarrierSet::_oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                OrderAccess::release_store_ptr(p, v);
                post_barrier(p, v); // Non-virtual
              }

          Otherwise

              GCBarrierSet::oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                *p = v;
                post_barrier(p, v); // Non-virtual
              }

          This way we'd reduce the number of virtual calls to 1. Plus, GCs that don't actually need a pre- or post-barrier (e.g. Shenandoah doesn't require post-barriers) can leave them out altogether. And as an aside, the above interface would actually belong into BarrierSet, and thus get called through the cached BarrierSet instance as for the current pre-barrier and post-barrier calls.

          And since oop_store() in oop.inline.hpp basically does the same, it could reuse the exact same GC interface.


          Alternatives
          ------------

          The current GC interface consists of:

          - CollectorPolicy
          - BarrierSet
          - CollectedHeap

          We could work from there, and extend them to achieve separation. However, it has several problems:

          - CollectedHeap is already very big and loaded with functionality that doesn't really concern the heap.
          - BarrierSet provides a good basis, but needs cleanup (remove unused stuff) and extensions for C1, C2 and interpreter.

          I am leaning to make a new GCInterface, that would be implemented by each GC, and provides a CollectorPolicy, CollectedHeap and BarrierSet, plus any new GC interface related things that are needed (e.g. GCServicabilitySupport, etc).

          Testing
          -------

          This is purely refactoring. Everything that worked before needs to work afterwards.


          Risks and Assumptions
          ---------------------

          A GC interface adds complexity. Currently stable & tested code in all collectors need to be changed. We hope that the benefit of clean and strict interface between GCs and the rest of Hotspot outweights the cost and risk of changes.

          We may not be able to implement it without harming performance.

          We may fail to identify and/or isolate all the touch points between GC and rest of the JVM.

          A first prototype would be implemented by focusing on code that directly includes gc/cms files, and abstract that out into GC interface code. This will allow us to identify obvious problems early on and address them.
          I suggest to integrate the majority of changes required for the GC interface at once, in order to get a fairly uniform treatment of all cases. Interpreter, C1 and C2 could be addressed in additional steps.

          A current snapshot of my work-in-progress can be found here: http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.00/


          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 keep it maintained by the OpenJDK community 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. The GCInterface needs to be extended to account for Shenandoah's read- and write-barriers though. Shenandoah requires read- and write-barriers in BarrierSet (for each of: runtime, interpreter, c1 and c2) plus the corresponding hooks all over the runtime, interpreter, c1 and c2. This change is very significant and would need to be discussed as part of the Shenandoah JEP. We added methods read_barrier() and write_barrier() and obj_equals() to BarrierSet, as well as all the corresponding hooks in the runtime, plus equivalent code generation in the interpreter, C1 and C2.


          - [1] http://openjdk.java.net/jeps/291
          - [2] http://openjdk.java.net/jeps/189
          rkennke Roman Kennke made changes -
          Status Draft [ 10001 ] Submitted [ 10002 ]
          shade Aleksey Shipilev made changes -
          Link This issue relates to JDK-8174901 [ JDK-8174901 ]
          Show
          rkennke Roman Kennke added a comment - I have posted an updated snapshot: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019665.html and http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.02/
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8179259 [ JDK-8179259 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8179260 [ JDK-8179260 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8179261 [ JDK-8179261 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8179268 [ JDK-8179268 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8179387 [ JDK-8179387 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8154343 [ JDK-8154343 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8180194 [ JDK-8180194 ]
          mr Mark Reinhold made changes -
          Description Summary
          -------

          Improve build-time isolation of different garbage collectors by designing a clean GC interface.

          Goals
          -----

          - Better modularity
          - Making it simpler to add a new GC to Hotspot without perturbing the current code base
          - Likewise, make it easier to exclude a GC from OpenJDK build

          Non-Goals
          ---------

          - It is not a goal to actually add or remove a GC

          Success Metrics
          ---------------

          The implementation is considered a success, if GC implementations are completely contained within source files in their src/share/vm/gc/$NAME and maybe src/cpu/share/vm/gc/$NAME directories. No code outside of those directories should include files from within those directories, nor should there be any GC-specific if-else branches. Code for one GC implementation must only depend on code in src/share/vm/gc/shared and its own subdirectory.

          Performance must not be negatively impacted.

          Motivation
          ----------

          Currently, each garbage collector implementation consists of source files inside their src/share/vm/gc/$NAME directories, e.g. G1 is in src/share/vm/gc/g1, CMS in src/share/vm/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 are not implemented by the GC that require them, but ususally in place, guarded by if-else-chains testing for specific GC implementations currently in use. Likewise, there are other small pieces of code in various places that are treated like this.

          This has several disadvantages.

          1. For GC implementors, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
          2. It is difficult to exclude, at build time, specific garbage collector(s). This has recently come up with the proposal to deprecate the CMS collector (JEP 291). Similarily, the INCLUDE_ALL_GCS has long been a way to build the JVM with only the serial collector built-in.

          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.

          Extensibility: 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 the runtime, interpreter, C1 and C2 that needs changing. A new garbage collector may require new interfaces (like for example, Shenandoah requires read- and write barriers, even for primitive type memory access). We acknowledge that there is no one GC algorithm which suits everyone's needs. Also, new memory architectures may require new/changed interfaces. The GC interfaces should allow for relatively easy extensions.

          The interface should be designed with JVMCI in mind, it should be clear to an implementation of JVMCI what to implement and how in order to support which GC(s).

          Last but not least, a clean GC interface would help tremendously with inclusion of new GCs like Shenandoah (JEP 189).


          Description
          -----------

          The idea is that the GC interface would be defined by a single class named GCInterface. Every collector needs to implement that. The GCInterface class would drive all aspects of interaction between the garbage collector and the rest of hotspot:

          - A specific instance of GCInterface would be created by a factory method (probably the only method in shared code with knowledge about specific GCs).
          The GCInterface provides:
          - 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 and AdaptiveSizePolicy
          - 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
          - VM argument initialization (what is currently scattered over arguments.cpp)
          - Eventually, we might consider moving non-heap related GC interface methods from CollectedHeap to GCInterface.
          - Setup of MemoryService, the related memory pools, memory managers, etc.
          - Safepointing the GC thread(s) should reuse SuspendibleThreadSet if possible/feasible.
          - Code (in the runtime, interpreter, C1 and C2) that currently has if-else switches to do GC specific things need to be changed to call the corresponding GCInterface

          During JIT and interpreter compilation, the barriers for the interpreter and C1 and C2 compilers would be generated by the GC, through a virtual call, e.g. oopDesc::bs()->c1_support()->pre_barrier(...).

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implemenations that need it. 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 CardTable 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. It needs to be determined yet on where such helper code should be kept. E.g. for C2-specific barrier code, should it be in src/share/vm/gc/shared or src/share/vm/opto or maybe some subdirectory-combination like src/share/vm/gc/shared/c2 ? Or even a separate directory altogether?


          ### Example

          To give one example to illustrate the approach I'd like to take for the GC interface. It came out of an earlier discussion I had with Jon:

          klass_oop_store() in klass.cpp

              void Klass::klass_oop_store(oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                // do the store
                if (always_do_update_barrier) {
                  klass_oop_store((volatile oop*)p, v);
                } else {
                  klass_update_barrier_set_pre(p, v);
                  *p = v;
                  klass_update_barrier_set(v);
                }
              }
               
              void Klass::klass_oop_store(volatile oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                klass_update_barrier_set_pre((oop*)p, v); // Cast away volatile.
                OrderAccess::release_store_ptr(p, v);
                klass_update_barrier_set(v);
              }

          "always_do_update_barrier" is only going to be true for
          CMS currently.

          With the GCInterface there would be a call into GC specific code that
          would do the actual store? Something like

              void Klass::klass_oop_store(oop* p, oop v) {
                // The following should actually be done statically once, somewhere else.
                // It's only here to demonstrate the mechanics of the GC interface.
                GCInterface* gci = GCInterface::get_interface();
                BarrierSet* bs = gci->barrier_set();
                bs->oop_store(p, v);
              }

          For GC's that need the memory barrier

              GCBarrierSet::_oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                OrderAccess::release_store_ptr(p, v);
                post_barrier(p, v); // Non-virtual
              }

          Otherwise

              GCBarrierSet::oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                *p = v;
                post_barrier(p, v); // Non-virtual
              }

          This way we'd reduce the number of virtual calls to 1. Plus, GCs that don't actually need a pre- or post-barrier (e.g. Shenandoah doesn't require post-barriers) can leave them out altogether. And as an aside, the above interface would actually belong into BarrierSet, and thus get called through the cached BarrierSet instance as for the current pre-barrier and post-barrier calls.

          And since oop_store() in oop.inline.hpp basically does the same, it could reuse the exact same GC interface.


          Alternatives
          ------------

          The current GC interface consists of:

          - CollectorPolicy
          - BarrierSet
          - CollectedHeap

          We could work from there, and extend them to achieve separation. However, it has several problems:

          - CollectedHeap is already very big and loaded with functionality that doesn't really concern the heap.
          - BarrierSet provides a good basis, but needs cleanup (remove unused stuff) and extensions for C1, C2 and interpreter.

          I am leaning to make a new GCInterface, that would be implemented by each GC, and provides a CollectorPolicy, CollectedHeap and BarrierSet, plus any new GC interface related things that are needed (e.g. GCServicabilitySupport, etc).

          Testing
          -------

          This is purely refactoring. Everything that worked before needs to work afterwards.


          Risks and Assumptions
          ---------------------

          A GC interface adds complexity. Currently stable & tested code in all collectors need to be changed. We hope that the benefit of clean and strict interface between GCs and the rest of Hotspot outweights the cost and risk of changes.

          We may not be able to implement it without harming performance.

          We may fail to identify and/or isolate all the touch points between GC and rest of the JVM.

          A first prototype would be implemented by focusing on code that directly includes gc/cms files, and abstract that out into GC interface code. This will allow us to identify obvious problems early on and address them.
          I suggest to integrate the majority of changes required for the GC interface at once, in order to get a fairly uniform treatment of all cases. Interpreter, C1 and C2 could be addressed in additional steps.

          A current snapshot of my work-in-progress can be found here: http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.00/


          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 keep it maintained by the OpenJDK community 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. The GCInterface needs to be extended to account for Shenandoah's read- and write-barriers though. Shenandoah requires read- and write-barriers in BarrierSet (for each of: runtime, interpreter, c1 and c2) plus the corresponding hooks all over the runtime, interpreter, c1 and c2. This change is very significant and would need to be discussed as part of the Shenandoah JEP. We added methods read_barrier() and write_barrier() and obj_equals() to BarrierSet, as well as all the corresponding hooks in the runtime, plus equivalent code generation in the interpreter, C1 and C2.


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

          Improve the build-time isolation of different garbage collectors by designing a clean GC interface.


          Goals
          -----

          - Better modularity
          - Make it simpler to add a new GC to HotSpot without perturbing the current code base
          - Likewise, 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


          Success Metrics
          ---------------

          The implementation is considered a success if GC implementations are completely contained within source files in their `src/share/vm/gc/$NAME` and maybe `src/cpu/share/vm/gc/$NAME` directories. No code outside of those directories should include files from within those directories, nor should there be any GC-specific `if`-`else` branches. Code for one GC implementation must only depend on code in `src/share/vm/gc/shared` and its own subdirectory.

          Performance must not be negatively impacted.


          Motivation
          ----------

          Currently, each garbage collector implementation consists of source files inside their `src/share/vm/gc/$NAME` directories, e.g. G1 is in `src/share/vm/gc/g1`, CMS in `src/share/vm/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 are not implemented by the GC that require them, but ususally in place, guarded by `if`-`else`-chains testing for specific GC implementations currently in use. Likewise, there are other small pieces of code in various places that are treated like this.

          This has several disadvantages.

          1. For GC implementors, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
          2. It is difficult to exclude, at build time, specific garbage collector(s). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing. A new garbage collector may require new interfaces (like for example, Shenandoah requires read- and write barriers, even for primitive type memory access). We acknowledge that there is no one GC algorithm which suits everyone's needs. Also, new memory architectures may require new/changed interfaces. The GC interfaces should allow for relatively easy extensions.

          The interface should be designed with JVMCI in mind. It should be clear to an implementation of JVMCI what to implement and how in order to support which GC(s).

          Last but not least, a clean GC interface would help tremendously with inclusion of new GCs such as Shenandoah ([JEP 189][2]).


          Description
          -----------

          The idea is that the GC interface would be defined by a single class named `GCInterface`. Every collector needs to implement that. The `GCInterface` class would drive all aspects of interaction between the garbage collector and the rest of HotSpot:

          - A specific instance of `GCInterface` would be created by a factory method (probably the only method in shared code with knowledge about specific GCs).
          The `GCInterface` provides:
          - 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` and `AdaptiveSizePolicy`
          - 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Eventually, we might consider moving non-heap related GC interface methods from `CollectedHeap` to `GCInterface`.
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Safepointing the GC thread(s) should reuse `SuspendibleThreadSet` if possible/feasible.
          - Code (in the runtime, interpreter, C1 and C2) that currently has `if`-`else` switches to do GC specific things need to be changed to call the corresponding `GCInterface`

          During JIT and interpreter compilation, the barriers for the interpreter and C1 and C2 compilers would be generated by the GC, through a virtual call, e.g. `oopDesc::bs()->c1_support()->pre_barrier(...)`.

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implemenations that need it. 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 `CardTable` 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. It needs to be determined yet on where such helper code should be kept. E.g. for C2-specific barrier code, should it be in `src/share/vm/gc/shared` or `src/share/vm/opto` or maybe some subdirectory-combination like `src/share/vm/gc/shared/c2`, or even a separate directory altogether?


          ### Example

          To give one example to illustrate one possible approach:

          klass_oop_store() in klass.cpp

              void Klass::klass_oop_store(oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                // do the store
                if (always_do_update_barrier) {
                  klass_oop_store((volatile oop*)p, v);
                } else {
                  klass_update_barrier_set_pre(p, v);
                  *p = v;
                  klass_update_barrier_set(v);
                }
              }
               
              void Klass::klass_oop_store(volatile oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                klass_update_barrier_set_pre((oop*)p, v); // Cast away volatile.
                OrderAccess::release_store_ptr(p, v);
                klass_update_barrier_set(v);
              }

          `always_do_update_barrier` is only going to be true for
          CMS currently.

          With the `GCInterface` there would be a call into GC specific code that
          would do the actual store, something like

              void Klass::klass_oop_store(oop* p, oop v) {
                // The following should actually be done statically once, somewhere else.
                // It's only here to demonstrate the mechanics of the GC interface.
                `GCInterface`* gci = `GCInterface`::get_interface();
                BarrierSet* bs = gci->barrier_set();
                bs->oop_store(p, v);
              }

          For GC's that need the memory barrier

              GCBarrierSet::_oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                OrderAccess::release_store_ptr(p, v);
                post_barrier(p, v); // Non-virtual
              }

          Otherwise

              GCBarrierSet::oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                *p = v;
                post_barrier(p, v); // Non-virtual
              }

          This way we'd reduce the number of virtual calls to 1. Plus, GCs that don't actually need a pre- or post-barrier (e.g. Shenandoah doesn't require post-barriers) can leave them out altogether. And as an aside, the above interface would actually belong into `BarrierSet`, and thus get called through the cached `BarrierSet` instance as for the current pre-barrier and post-barrier calls.

          And since `oop_store()` in `oop.inline.hpp` basically does the same, it could reuse the exact same GC interface.


          Alternatives
          ------------

          The current GC interface consists of:

          - `CollectorPolicy`
          - `BarrierSet`
          - `CollectedHeap`

          We could work from there, and extend them to achieve separation. However, it has several problems:

          - `CollectedHeap` is already very big and loaded with functionality that doesn't really concern the heap.
          - `BarrierSet` provides a good basis, but needs cleanup (remove unused stuff) and extensions for C1, C2 and interpreter.

          I am leaning to make a new `GCInterface`, that would be implemented by each GC, and provides a `CollectorPolicy`, `CollectedHeap`, and `BarrierSet`, plus any new GC interface related things that are needed (e.g. `GCServicabilitySupport`, etc.).

          Testing
          -------

          This is purely refactoring. Everything that worked before needs to work afterwards.


          Risks and Assumptions
          ---------------------

          A GC interface adds complexity. Currently stable and tested code in all collectors need to be changed. We hope that the benefit of clean and strict interface between GCs and the rest of HotSpot outweights the cost and risk of changes.

          We may not be able to implement it without harming performance.

          We may fail to identify and/or isolate all the touch points between GC and rest of the JVM.

          A first prototype would be implemented by focusing on code that directly includes `gc/cms` files, and abstract that out into GC interface code. This will allow us to identify obvious problems early on and address them.
          I suggest to integrate the majority of changes required for the GC interface at once, in order to get a fairly uniform treatment of all cases. Interpreter, C1, and C2 could be addressed in additional steps.

          A current snapshot of the work-in-progress can be found [here](http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.00/).


          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. The `GCInterface` needs to be extended to account for Shenandoah's read- and write-barriers though. Shenandoah requires read- and write-barriers in `BarrierSet` (for each of: runtime, interpreter, c1 and c2) plus the corresponding hooks all over the runtime, interpreter, c1 and c2. This change is very significant and would need to be discussed as part of the Shenandoah JEP. We added methods `read_barrier()` and `write_barrier()` and `obj_equals()` to `BarrierSet`, as well as all the corresponding hooks in the runtime, plus equivalent code generation in the interpreter, C1 and C2.


          [1]: http://openjdk.java.net/jeps/291
          [2]: http://openjdk.java.net/jeps/189
          mr Mark Reinhold made changes -
          Summary GC Interface: Better isolation of GC implementations Garbage-Collector Interface
          mr Mark Reinhold made changes -
          Status Submitted [ 10002 ] Candidate [ 10003 ]
          JEP Number 304
          mr Mark Reinhold made changes -
          Summary Garbage-Collector Interface JEP 304: Garbage-Collector Interface
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8183542 [ JDK-8183542 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8184181 [ JDK-8184181 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8184914 [ JDK-8184914 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8189171 [ JDK-8189171 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8189276 [ JDK-8189276 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8189364 [ JDK-8189364 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8189389 [ JDK-8189389 ]
          rkennke Roman Kennke made changes -
          Description Summary
          -------

          Improve the build-time isolation of different garbage collectors by designing a clean GC interface.


          Goals
          -----

          - Better modularity
          - Make it simpler to add a new GC to HotSpot without perturbing the current code base
          - Likewise, 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


          Success Metrics
          ---------------

          The implementation is considered a success if GC implementations are completely contained within source files in their `src/share/vm/gc/$NAME` and maybe `src/cpu/share/vm/gc/$NAME` directories. No code outside of those directories should include files from within those directories, nor should there be any GC-specific `if`-`else` branches. Code for one GC implementation must only depend on code in `src/share/vm/gc/shared` and its own subdirectory.

          Performance must not be negatively impacted.


          Motivation
          ----------

          Currently, each garbage collector implementation consists of source files inside their `src/share/vm/gc/$NAME` directories, e.g. G1 is in `src/share/vm/gc/g1`, CMS in `src/share/vm/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 are not implemented by the GC that require them, but ususally in place, guarded by `if`-`else`-chains testing for specific GC implementations currently in use. Likewise, there are other small pieces of code in various places that are treated like this.

          This has several disadvantages.

          1. For GC implementors, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
          2. It is difficult to exclude, at build time, specific garbage collector(s). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing. A new garbage collector may require new interfaces (like for example, Shenandoah requires read- and write barriers, even for primitive type memory access). We acknowledge that there is no one GC algorithm which suits everyone's needs. Also, new memory architectures may require new/changed interfaces. The GC interfaces should allow for relatively easy extensions.

          The interface should be designed with JVMCI in mind. It should be clear to an implementation of JVMCI what to implement and how in order to support which GC(s).

          Last but not least, a clean GC interface would help tremendously with inclusion of new GCs such as Shenandoah ([JEP 189][2]).


          Description
          -----------

          The idea is that the GC interface would be defined by a single class named `GCInterface`. Every collector needs to implement that. The `GCInterface` class would drive all aspects of interaction between the garbage collector and the rest of HotSpot:

          - A specific instance of `GCInterface` would be created by a factory method (probably the only method in shared code with knowledge about specific GCs).
          The `GCInterface` provides:
          - 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` and `AdaptiveSizePolicy`
          - 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Eventually, we might consider moving non-heap related GC interface methods from `CollectedHeap` to `GCInterface`.
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Safepointing the GC thread(s) should reuse `SuspendibleThreadSet` if possible/feasible.
          - Code (in the runtime, interpreter, C1 and C2) that currently has `if`-`else` switches to do GC specific things need to be changed to call the corresponding `GCInterface`

          During JIT and interpreter compilation, the barriers for the interpreter and C1 and C2 compilers would be generated by the GC, through a virtual call, e.g. `oopDesc::bs()->c1_support()->pre_barrier(...)`.

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implemenations that need it. 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 `CardTable` 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. It needs to be determined yet on where such helper code should be kept. E.g. for C2-specific barrier code, should it be in `src/share/vm/gc/shared` or `src/share/vm/opto` or maybe some subdirectory-combination like `src/share/vm/gc/shared/c2`, or even a separate directory altogether?


          ### Example

          To give one example to illustrate one possible approach:

          klass_oop_store() in klass.cpp

              void Klass::klass_oop_store(oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                // do the store
                if (always_do_update_barrier) {
                  klass_oop_store((volatile oop*)p, v);
                } else {
                  klass_update_barrier_set_pre(p, v);
                  *p = v;
                  klass_update_barrier_set(v);
                }
              }
               
              void Klass::klass_oop_store(volatile oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                klass_update_barrier_set_pre((oop*)p, v); // Cast away volatile.
                OrderAccess::release_store_ptr(p, v);
                klass_update_barrier_set(v);
              }

          `always_do_update_barrier` is only going to be true for
          CMS currently.

          With the `GCInterface` there would be a call into GC specific code that
          would do the actual store, something like

              void Klass::klass_oop_store(oop* p, oop v) {
                // The following should actually be done statically once, somewhere else.
                // It's only here to demonstrate the mechanics of the GC interface.
                `GCInterface`* gci = `GCInterface`::get_interface();
                BarrierSet* bs = gci->barrier_set();
                bs->oop_store(p, v);
              }

          For GC's that need the memory barrier

              GCBarrierSet::_oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                OrderAccess::release_store_ptr(p, v);
                post_barrier(p, v); // Non-virtual
              }

          Otherwise

              GCBarrierSet::oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                *p = v;
                post_barrier(p, v); // Non-virtual
              }

          This way we'd reduce the number of virtual calls to 1. Plus, GCs that don't actually need a pre- or post-barrier (e.g. Shenandoah doesn't require post-barriers) can leave them out altogether. And as an aside, the above interface would actually belong into `BarrierSet`, and thus get called through the cached `BarrierSet` instance as for the current pre-barrier and post-barrier calls.

          And since `oop_store()` in `oop.inline.hpp` basically does the same, it could reuse the exact same GC interface.


          Alternatives
          ------------

          The current GC interface consists of:

          - `CollectorPolicy`
          - `BarrierSet`
          - `CollectedHeap`

          We could work from there, and extend them to achieve separation. However, it has several problems:

          - `CollectedHeap` is already very big and loaded with functionality that doesn't really concern the heap.
          - `BarrierSet` provides a good basis, but needs cleanup (remove unused stuff) and extensions for C1, C2 and interpreter.

          I am leaning to make a new `GCInterface`, that would be implemented by each GC, and provides a `CollectorPolicy`, `CollectedHeap`, and `BarrierSet`, plus any new GC interface related things that are needed (e.g. `GCServicabilitySupport`, etc.).

          Testing
          -------

          This is purely refactoring. Everything that worked before needs to work afterwards.


          Risks and Assumptions
          ---------------------

          A GC interface adds complexity. Currently stable and tested code in all collectors need to be changed. We hope that the benefit of clean and strict interface between GCs and the rest of HotSpot outweights the cost and risk of changes.

          We may not be able to implement it without harming performance.

          We may fail to identify and/or isolate all the touch points between GC and rest of the JVM.

          A first prototype would be implemented by focusing on code that directly includes `gc/cms` files, and abstract that out into GC interface code. This will allow us to identify obvious problems early on and address them.
          I suggest to integrate the majority of changes required for the GC interface at once, in order to get a fairly uniform treatment of all cases. Interpreter, C1, and C2 could be addressed in additional steps.

          A current snapshot of the work-in-progress can be found [here](http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.00/).


          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. The `GCInterface` needs to be extended to account for Shenandoah's read- and write-barriers though. Shenandoah requires read- and write-barriers in `BarrierSet` (for each of: runtime, interpreter, c1 and c2) plus the corresponding hooks all over the runtime, interpreter, c1 and c2. This change is very significant and would need to be discussed as part of the Shenandoah JEP. We added methods `read_barrier()` and `write_barrier()` and `obj_equals()` to `BarrierSet`, as well as all the corresponding hooks in the runtime, plus equivalent code generation in the interpreter, C1 and C2.


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

          Improve the build-time isolation of different garbage collectors by designing a clean GC interface.


          Goals
          -----

          - Better modularity
          - Make it simpler to add a new GC to HotSpot without perturbing the current code base
          - Likewise, 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


          Success Metrics
          ---------------

          The implementation is considered a success if GC implementations are completely contained within source files in their `src/share/vm/gc/$NAME` and maybe `src/cpu/share/vm/gc/$NAME` directories. No code outside of those directories should include files from within those directories, nor should there be any GC-specific `if`-`else` branches. Code for one GC implementation must only depend on code in `src/share/vm/gc/shared` and its own subdirectory.

          Performance must not be negatively impacted.


          Motivation
          ----------

          Currently, each garbage collector implementation consists of source files inside their `src/share/vm/gc/$NAME` directories, e.g. G1 is in `src/share/vm/gc/g1`, CMS in `src/share/vm/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 are not implemented by the GC that require them, but ususally in place, guarded by `if`-`else`-chains testing for specific GC implementations currently in use. Likewise, there are other small pieces of code in various places that are treated like this.

          This has several disadvantages.

          1. For GC implementors, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
          2. It is difficult to exclude, at build time, specific garbage collector(s). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing. A new garbage collector may require new interfaces (like for example, Shenandoah requires read- and write barriers, even for primitive type memory access). We acknowledge that there is no one GC algorithm which suits everyone's needs. Also, new memory architectures may require new/changed interfaces. The GC interfaces should allow for relatively easy extensions.

          The interface should be designed with JVMCI in mind. It should be clear to an implementation of JVMCI what to implement and how in order to support which GC(s).

          Last but not least, a clean GC interface would help tremendously with inclusion of new GCs such as Shenandoah ([JEP 189][2]).


          Description
          -----------

          The idea is that the GC interface would be defined by a single class named `GCInterface`. Every collector needs to implement that. The `GCInterface` class would drive all aspects of interaction between the garbage collector and the rest of HotSpot:

          - A specific instance of `GCInterface` would be created by a factory method (probably the only method in shared code with knowledge about specific GCs).
          The `GCInterface` provides:
          - 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` and `AdaptiveSizePolicy`
          - 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Eventually, we might consider moving non-heap related GC interface methods from `CollectedHeap` to `GCInterface`.
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Safepointing the GC thread(s) should reuse `SuspendibleThreadSet` if possible/feasible.
          - Code (in the runtime, interpreter, C1 and C2) that currently has `if`-`else` switches to do GC specific things need to be changed to call the corresponding `GCInterface`

          During JIT and interpreter compilation, the barriers for the interpreter and C1 and C2 compilers would be generated by the GC, through a virtual call, e.g. `oopDesc::bs()->c1_support()->pre_barrier(...)`.

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implemenations that need it. 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 `CardTable` 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. It needs to be determined yet on where such helper code should be kept. E.g. for C2-specific barrier code, should it be in `src/share/vm/gc/shared` or `src/share/vm/opto` or maybe some subdirectory-combination like `src/share/vm/gc/shared/c2`, or even a separate directory altogether?


          ### Example

          To give one example to illustrate one possible approach:

          klass_oop_store() in klass.cpp

              void Klass::klass_oop_store(oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                // do the store
                if (always_do_update_barrier) {
                  klass_oop_store((volatile oop*)p, v);
                } else {
                  klass_update_barrier_set_pre(p, v);
                  *p = v;
                  klass_update_barrier_set(v);
                }
              }
               
              void Klass::klass_oop_store(volatile oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                klass_update_barrier_set_pre((oop*)p, v); // Cast away volatile.
                OrderAccess::release_store_ptr(p, v);
                klass_update_barrier_set(v);
              }

          `always_do_update_barrier` is only going to be true for
          CMS currently.

          With the `GCInterface` there would be a call into GC specific code that
          would do the actual store, something like

              void Klass::klass_oop_store(oop* p, oop v) {
                // The following should actually be done statically once, somewhere else.
                // It's only here to demonstrate the mechanics of the GC interface.
                `GCInterface`* gci = `GCInterface`::get_interface();
                BarrierSet* bs = gci->barrier_set();
                bs->oop_store(p, v);
              }

          For GC's that need the memory barrier

              GCBarrierSet::_oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                OrderAccess::release_store_ptr(p, v);
                post_barrier(p, v); // Non-virtual
              }

          Otherwise

              GCBarrierSet::oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                *p = v;
                post_barrier(p, v); // Non-virtual
              }

          This way we'd reduce the number of virtual calls to 1. Plus, GCs that don't actually need a pre- or post-barrier (e.g. Shenandoah doesn't require post-barriers) can leave them out altogether. And as an aside, the above interface would actually belong into `BarrierSet`, and thus get called through the cached `BarrierSet` instance as for the current pre-barrier and post-barrier calls.

          And since `oop_store()` in `oop.inline.hpp` basically does the same, it could reuse the exact same GC interface.


          Alternatives
          ------------

          The current GC interface consists of:

          - `CollectorPolicy`
          - `BarrierSet`
          - `CollectedHeap`

          We could work from there, and extend them to achieve separation. However, it has several problems:

          - `CollectedHeap` is already very big and loaded with functionality that doesn't really concern the heap.
          - `BarrierSet` provides a good basis, but needs cleanup (remove unused stuff) and extensions for C1, C2 and interpreter.

          I am leaning to make a new `GCInterface`, that would be implemented by each GC, and provides a `CollectorPolicy`, `CollectedHeap`, and `BarrierSet`, plus any new GC interface related things that are needed (e.g. `GCServicabilitySupport`, etc.).

          Testing
          -------

          This is purely refactoring. Everything that worked before needs to work afterwards.

          Documentation
          -------------

          Updated documentation is not needed because this is an internal refactoring.

          Performance
          -----------

          The performance must not regress due to this refactoring.

          Risks and Assumptions
          ---------------------

          A GC interface adds complexity. Currently stable and tested code in all collectors need to be changed. We hope that the benefit of clean and strict interface between GCs and the rest of HotSpot outweights the cost and risk of changes.

          We may not be able to implement it without harming performance.

          We may fail to identify and/or isolate all the touch points between GC and rest of the JVM.

          A first prototype would be implemented by focusing on code that directly includes `gc/cms` files, and abstract that out into GC interface code. This will allow us to identify obvious problems early on and address them.
          I suggest to integrate the majority of changes required for the GC interface at once, in order to get a fairly uniform treatment of all cases. Interpreter, C1, and C2 could be addressed in additional steps.

          A current snapshot of the work-in-progress can be found [here](http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.00/).


          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. The `GCInterface` needs to be extended to account for Shenandoah's read- and write-barriers though. Shenandoah requires read- and write-barriers in `BarrierSet` (for each of: runtime, interpreter, c1 and c2) plus the corresponding hooks all over the runtime, interpreter, c1 and c2. This change is very significant and would need to be discussed as part of the Shenandoah JEP. We added methods `read_barrier()` and `write_barrier()` and `obj_equals()` to `BarrierSet`, as well as all the corresponding hooks in the runtime, plus equivalent code generation in the interpreter, C1 and C2.


          [1]: http://openjdk.java.net/jeps/291
          [2]: http://openjdk.java.net/jeps/189
          eosterlund Erik Österlund made changes -
          Description Summary
          -------

          Improve the build-time isolation of different garbage collectors by designing a clean GC interface.


          Goals
          -----

          - Better modularity
          - Make it simpler to add a new GC to HotSpot without perturbing the current code base
          - Likewise, 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


          Success Metrics
          ---------------

          The implementation is considered a success if GC implementations are completely contained within source files in their `src/share/vm/gc/$NAME` and maybe `src/cpu/share/vm/gc/$NAME` directories. No code outside of those directories should include files from within those directories, nor should there be any GC-specific `if`-`else` branches. Code for one GC implementation must only depend on code in `src/share/vm/gc/shared` and its own subdirectory.

          Performance must not be negatively impacted.


          Motivation
          ----------

          Currently, each garbage collector implementation consists of source files inside their `src/share/vm/gc/$NAME` directories, e.g. G1 is in `src/share/vm/gc/g1`, CMS in `src/share/vm/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 are not implemented by the GC that require them, but ususally in place, guarded by `if`-`else`-chains testing for specific GC implementations currently in use. Likewise, there are other small pieces of code in various places that are treated like this.

          This has several disadvantages.

          1. For GC implementors, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
          2. It is difficult to exclude, at build time, specific garbage collector(s). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing. A new garbage collector may require new interfaces (like for example, Shenandoah requires read- and write barriers, even for primitive type memory access). We acknowledge that there is no one GC algorithm which suits everyone's needs. Also, new memory architectures may require new/changed interfaces. The GC interfaces should allow for relatively easy extensions.

          The interface should be designed with JVMCI in mind. It should be clear to an implementation of JVMCI what to implement and how in order to support which GC(s).

          Last but not least, a clean GC interface would help tremendously with inclusion of new GCs such as Shenandoah ([JEP 189][2]).


          Description
          -----------

          The idea is that the GC interface would be defined by a single class named `GCInterface`. Every collector needs to implement that. The `GCInterface` class would drive all aspects of interaction between the garbage collector and the rest of HotSpot:

          - A specific instance of `GCInterface` would be created by a factory method (probably the only method in shared code with knowledge about specific GCs).
          The `GCInterface` provides:
          - 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` and `AdaptiveSizePolicy`
          - 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Eventually, we might consider moving non-heap related GC interface methods from `CollectedHeap` to `GCInterface`.
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Safepointing the GC thread(s) should reuse `SuspendibleThreadSet` if possible/feasible.
          - Code (in the runtime, interpreter, C1 and C2) that currently has `if`-`else` switches to do GC specific things need to be changed to call the corresponding `GCInterface`

          During JIT and interpreter compilation, the barriers for the interpreter and C1 and C2 compilers would be generated by the GC, through a virtual call, e.g. `oopDesc::bs()->c1_support()->pre_barrier(...)`.

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implemenations that need it. 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 `CardTable` 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. It needs to be determined yet on where such helper code should be kept. E.g. for C2-specific barrier code, should it be in `src/share/vm/gc/shared` or `src/share/vm/opto` or maybe some subdirectory-combination like `src/share/vm/gc/shared/c2`, or even a separate directory altogether?


          ### Example

          To give one example to illustrate one possible approach:

          klass_oop_store() in klass.cpp

              void Klass::klass_oop_store(oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                // do the store
                if (always_do_update_barrier) {
                  klass_oop_store((volatile oop*)p, v);
                } else {
                  klass_update_barrier_set_pre(p, v);
                  *p = v;
                  klass_update_barrier_set(v);
                }
              }
               
              void Klass::klass_oop_store(volatile oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                klass_update_barrier_set_pre((oop*)p, v); // Cast away volatile.
                OrderAccess::release_store_ptr(p, v);
                klass_update_barrier_set(v);
              }

          `always_do_update_barrier` is only going to be true for
          CMS currently.

          With the `GCInterface` there would be a call into GC specific code that
          would do the actual store, something like

              void Klass::klass_oop_store(oop* p, oop v) {
                // The following should actually be done statically once, somewhere else.
                // It's only here to demonstrate the mechanics of the GC interface.
                `GCInterface`* gci = `GCInterface`::get_interface();
                BarrierSet* bs = gci->barrier_set();
                bs->oop_store(p, v);
              }

          For GC's that need the memory barrier

              GCBarrierSet::_oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                OrderAccess::release_store_ptr(p, v);
                post_barrier(p, v); // Non-virtual
              }

          Otherwise

              GCBarrierSet::oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                *p = v;
                post_barrier(p, v); // Non-virtual
              }

          This way we'd reduce the number of virtual calls to 1. Plus, GCs that don't actually need a pre- or post-barrier (e.g. Shenandoah doesn't require post-barriers) can leave them out altogether. And as an aside, the above interface would actually belong into `BarrierSet`, and thus get called through the cached `BarrierSet` instance as for the current pre-barrier and post-barrier calls.

          And since `oop_store()` in `oop.inline.hpp` basically does the same, it could reuse the exact same GC interface.


          Alternatives
          ------------

          The current GC interface consists of:

          - `CollectorPolicy`
          - `BarrierSet`
          - `CollectedHeap`

          We could work from there, and extend them to achieve separation. However, it has several problems:

          - `CollectedHeap` is already very big and loaded with functionality that doesn't really concern the heap.
          - `BarrierSet` provides a good basis, but needs cleanup (remove unused stuff) and extensions for C1, C2 and interpreter.

          I am leaning to make a new `GCInterface`, that would be implemented by each GC, and provides a `CollectorPolicy`, `CollectedHeap`, and `BarrierSet`, plus any new GC interface related things that are needed (e.g. `GCServicabilitySupport`, etc.).

          Testing
          -------

          This is purely refactoring. Everything that worked before needs to work afterwards.

          Documentation
          -------------

          Updated documentation is not needed because this is an internal refactoring.

          Performance
          -----------

          The performance must not regress due to this refactoring.

          Risks and Assumptions
          ---------------------

          A GC interface adds complexity. Currently stable and tested code in all collectors need to be changed. We hope that the benefit of clean and strict interface between GCs and the rest of HotSpot outweights the cost and risk of changes.

          We may not be able to implement it without harming performance.

          We may fail to identify and/or isolate all the touch points between GC and rest of the JVM.

          A first prototype would be implemented by focusing on code that directly includes `gc/cms` files, and abstract that out into GC interface code. This will allow us to identify obvious problems early on and address them.
          I suggest to integrate the majority of changes required for the GC interface at once, in order to get a fairly uniform treatment of all cases. Interpreter, C1, and C2 could be addressed in additional steps.

          A current snapshot of the work-in-progress can be found [here](http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.00/).


          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. The `GCInterface` needs to be extended to account for Shenandoah's read- and write-barriers though. Shenandoah requires read- and write-barriers in `BarrierSet` (for each of: runtime, interpreter, c1 and c2) plus the corresponding hooks all over the runtime, interpreter, c1 and c2. This change is very significant and would need to be discussed as part of the Shenandoah JEP. We added methods `read_barrier()` and `write_barrier()` and `obj_equals()` to `BarrierSet`, as well as all the corresponding hooks in the runtime, plus equivalent code generation in the interpreter, C1 and C2.


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

          Improve the build-time isolation of different garbage collectors by designing a clean 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
          - Likewise, 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 is considered a success if GC implementations are mostly contained within source files in their `src/hotspot/share/gc/$NAME` and maybe `src/hotspot/cpu/share/vm/gc/$NAME` directories. Minimal code outside of those directories should include files from within those directories, and there should be very few GC-specific `if`-`else` branches. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Performance should not be negatively impacted due to this refactoring.

          Motivation
          ----------

          Currently, each garbage collector implementation 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 are not implemented by the GC that require them, but usually in place, guarded by `if`-`else`-chains testing for specific GC implementations currently in use. Likewise, there are other small pieces of code in various places that are treated like this.

          This has several disadvantages.

          1. For GC implementors, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
          2. It is difficult to exclude, at build time, specific garbage collector(s). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing. A new garbage collector may require new interfaces (like for example, Shenandoah requires read- and write barriers, even for primitive type memory access). We acknowledge that there is no one GC algorithm which suits everyone's needs. Also, new memory architectures may require new/changed interfaces. The GC interfaces should allow for relatively easy extensions.

          The interface should be designed with JVMCI in mind. It should be clear to an implementation of JVMCI what to implement and how in order to support which GC(s).

          Last but not least, a clean GC interface would help tremendously with inclusion of new GCs such as Shenandoah ([JEP 189][2]).


          Description
          -----------

          The idea is that the GC interface would be defined by a single class named `GCInterface`. Every collector needs to implement that. The `GCInterface` class would drive all aspects of interaction between the garbage collector and the rest of HotSpot:

          - A specific instance of `GCInterface` would be created by a factory method (probably the only method in shared code with knowledge about specific GCs).
          The `GCInterface` provides:
          - 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` and `AdaptiveSizePolicy`
          - 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Eventually, we might consider moving non-heap related GC interface methods from `CollectedHeap` to `GCInterface`.
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Safepointing the GC thread(s) should reuse `SuspendibleThreadSet` if possible/feasible.
          - Code (in the runtime, interpreter, C1 and C2) that currently has `if`-`else` switches to do GC specific things need to be changed to call the corresponding `GCInterface`

          During JIT and interpreter compilation, the barriers for the interpreter and C1 and C2 compilers would be generated by the GC, through a virtual call, e.g. `oopDesc::bs()->c1_support()->pre_barrier(...)`.

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implemenations that need it. 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 `CardTable` 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. It needs to be determined yet on where such helper code should be kept. E.g. for C2-specific barrier code, should it be in `src/share/vm/gc/shared` or `src/share/vm/opto` or maybe some subdirectory-combination like `src/share/vm/gc/shared/c2`, or even a separate directory altogether?


          ### Example

          To give one example to illustrate one possible approach:

          klass_oop_store() in klass.cpp

              void Klass::klass_oop_store(oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                // do the store
                if (always_do_update_barrier) {
                  klass_oop_store((volatile oop*)p, v);
                } else {
                  klass_update_barrier_set_pre(p, v);
                  *p = v;
                  klass_update_barrier_set(v);
                }
              }
               
              void Klass::klass_oop_store(volatile oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                klass_update_barrier_set_pre((oop*)p, v); // Cast away volatile.
                OrderAccess::release_store_ptr(p, v);
                klass_update_barrier_set(v);
              }

          `always_do_update_barrier` is only going to be true for
          CMS currently.

          With the `GCInterface` there would be a call into GC specific code that
          would do the actual store, something like

              void Klass::klass_oop_store(oop* p, oop v) {
                // The following should actually be done statically once, somewhere else.
                // It's only here to demonstrate the mechanics of the GC interface.
                `GCInterface`* gci = `GCInterface`::get_interface();
                BarrierSet* bs = gci->barrier_set();
                bs->oop_store(p, v);
              }

          For GC's that need the memory barrier

              GCBarrierSet::_oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                OrderAccess::release_store_ptr(p, v);
                post_barrier(p, v); // Non-virtual
              }

          Otherwise

              GCBarrierSet::oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                *p = v;
                post_barrier(p, v); // Non-virtual
              }

          This way we'd reduce the number of virtual calls to 1. Plus, GCs that don't actually need a pre- or post-barrier (e.g. Shenandoah doesn't require post-barriers) can leave them out altogether. And as an aside, the above interface would actually belong into `BarrierSet`, and thus get called through the cached `BarrierSet` instance as for the current pre-barrier and post-barrier calls.

          And since `oop_store()` in `oop.inline.hpp` basically does the same, it could reuse the exact same GC interface.


          Alternatives
          ------------

          The current GC interface consists of:

          - `CollectorPolicy`
          - `BarrierSet`
          - `CollectedHeap`

          We could work from there, and extend them to achieve separation. However, it has several problems:

          - `CollectedHeap` is already very big and loaded with functionality that doesn't really concern the heap.
          - `BarrierSet` provides a good basis, but needs cleanup (remove unused stuff) and extensions for C1, C2 and interpreter.

          I am leaning to make a new `GCInterface`, that would be implemented by each GC, and provides a `CollectorPolicy`, `CollectedHeap`, and `BarrierSet`, plus any new GC interface related things that are needed (e.g. `GCServicabilitySupport`, etc.).

          Testing
          -------

          This is purely refactoring. Everything that worked before needs to work afterwards.

          Documentation
          -------------

          Updated documentation is not needed because this is an internal refactoring.

          Performance
          -----------

          The performance must not regress due to this refactoring.

          Risks and Assumptions
          ---------------------

          A GC interface adds complexity. Currently stable and tested code in all collectors need to be changed. We hope that the benefit of clean and strict interface between GCs and the rest of HotSpot outweights the cost and risk of changes.

          We may not be able to implement it without harming performance.

          We may fail to identify and/or isolate all the touch points between GC and rest of the JVM.

          A first prototype would be implemented by focusing on code that directly includes `gc/cms` files, and abstract that out into GC interface code. This will allow us to identify obvious problems early on and address them.
          I suggest to integrate the majority of changes required for the GC interface at once, in order to get a fairly uniform treatment of all cases. Interpreter, C1, and C2 could be addressed in additional steps.

          A current snapshot of the work-in-progress can be found [here](http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.00/).


          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. The `GCInterface` needs to be extended to account for Shenandoah's read- and write-barriers though. Shenandoah requires read- and write-barriers in `BarrierSet` (for each of: runtime, interpreter, c1 and c2) plus the corresponding hooks all over the runtime, interpreter, c1 and c2. This change is very significant and would need to be discussed as part of the Shenandoah JEP. We added methods `read_barrier()` and `write_barrier()` and `obj_equals()` to `BarrierSet`, as well as all the corresponding hooks in the runtime, plus equivalent code generation in the interpreter, C1 and C2.


          [1]: http://openjdk.java.net/jeps/291
          [2]: http://openjdk.java.net/jeps/189
          ehelin Erik Helin made changes -
          Summary JEP 304: Garbage-Collector Interface JEP 304: Garbage Collector Interface
          ehelin Erik Helin made changes -
          Description Summary
          -------

          Improve the build-time isolation of different garbage collectors by designing a clean 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
          - Likewise, 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 is considered a success if GC implementations are mostly contained within source files in their `src/hotspot/share/gc/$NAME` and maybe `src/hotspot/cpu/share/vm/gc/$NAME` directories. Minimal code outside of those directories should include files from within those directories, and there should be very few GC-specific `if`-`else` branches. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Performance should not be negatively impacted due to this refactoring.

          Motivation
          ----------

          Currently, each garbage collector implementation 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 are not implemented by the GC that require them, but usually in place, guarded by `if`-`else`-chains testing for specific GC implementations currently in use. Likewise, there are other small pieces of code in various places that are treated like this.

          This has several disadvantages.

          1. For GC implementors, implementing a new garbage collector requires knowledge about all those various places, and how to extend them for their specific needs.
          2. It is difficult to exclude, at build time, specific garbage collector(s). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing. A new garbage collector may require new interfaces (like for example, Shenandoah requires read- and write barriers, even for primitive type memory access). We acknowledge that there is no one GC algorithm which suits everyone's needs. Also, new memory architectures may require new/changed interfaces. The GC interfaces should allow for relatively easy extensions.

          The interface should be designed with JVMCI in mind. It should be clear to an implementation of JVMCI what to implement and how in order to support which GC(s).

          Last but not least, a clean GC interface would help tremendously with inclusion of new GCs such as Shenandoah ([JEP 189][2]).


          Description
          -----------

          The idea is that the GC interface would be defined by a single class named `GCInterface`. Every collector needs to implement that. The `GCInterface` class would drive all aspects of interaction between the garbage collector and the rest of HotSpot:

          - A specific instance of `GCInterface` would be created by a factory method (probably the only method in shared code with knowledge about specific GCs).
          The `GCInterface` provides:
          - 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` and `AdaptiveSizePolicy`
          - 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Eventually, we might consider moving non-heap related GC interface methods from `CollectedHeap` to `GCInterface`.
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Safepointing the GC thread(s) should reuse `SuspendibleThreadSet` if possible/feasible.
          - Code (in the runtime, interpreter, C1 and C2) that currently has `if`-`else` switches to do GC specific things need to be changed to call the corresponding `GCInterface`

          During JIT and interpreter compilation, the barriers for the interpreter and C1 and C2 compilers would be generated by the GC, through a virtual call, e.g. `oopDesc::bs()->c1_support()->pre_barrier(...)`.

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implemenations that need it. 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 `CardTable` 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. It needs to be determined yet on where such helper code should be kept. E.g. for C2-specific barrier code, should it be in `src/share/vm/gc/shared` or `src/share/vm/opto` or maybe some subdirectory-combination like `src/share/vm/gc/shared/c2`, or even a separate directory altogether?


          ### Example

          To give one example to illustrate one possible approach:

          klass_oop_store() in klass.cpp

              void Klass::klass_oop_store(oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                // do the store
                if (always_do_update_barrier) {
                  klass_oop_store((volatile oop*)p, v);
                } else {
                  klass_update_barrier_set_pre(p, v);
                  *p = v;
                  klass_update_barrier_set(v);
                }
              }
               
              void Klass::klass_oop_store(volatile oop* p, oop v) {
                assert(!Universe::heap()->is_in_reserved((void*)p), "Should store pointer into metadata ");
                assert(v == NULL || Universe::heap()->is_in_reserved((void*)v), "Should store pointer t o an object");
              
                klass_update_barrier_set_pre((oop*)p, v); // Cast away volatile.
                OrderAccess::release_store_ptr(p, v);
                klass_update_barrier_set(v);
              }

          `always_do_update_barrier` is only going to be true for
          CMS currently.

          With the `GCInterface` there would be a call into GC specific code that
          would do the actual store, something like

              void Klass::klass_oop_store(oop* p, oop v) {
                // The following should actually be done statically once, somewhere else.
                // It's only here to demonstrate the mechanics of the GC interface.
                `GCInterface`* gci = `GCInterface`::get_interface();
                BarrierSet* bs = gci->barrier_set();
                bs->oop_store(p, v);
              }

          For GC's that need the memory barrier

              GCBarrierSet::_oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                OrderAccess::release_store_ptr(p, v);
                post_barrier(p, v); // Non-virtual
              }

          Otherwise

              GCBarrierSet::oop_store(oop* p, oop v) {
                pre_barrier(p, v); // Non-virtual
                *p = v;
                post_barrier(p, v); // Non-virtual
              }

          This way we'd reduce the number of virtual calls to 1. Plus, GCs that don't actually need a pre- or post-barrier (e.g. Shenandoah doesn't require post-barriers) can leave them out altogether. And as an aside, the above interface would actually belong into `BarrierSet`, and thus get called through the cached `BarrierSet` instance as for the current pre-barrier and post-barrier calls.

          And since `oop_store()` in `oop.inline.hpp` basically does the same, it could reuse the exact same GC interface.


          Alternatives
          ------------

          The current GC interface consists of:

          - `CollectorPolicy`
          - `BarrierSet`
          - `CollectedHeap`

          We could work from there, and extend them to achieve separation. However, it has several problems:

          - `CollectedHeap` is already very big and loaded with functionality that doesn't really concern the heap.
          - `BarrierSet` provides a good basis, but needs cleanup (remove unused stuff) and extensions for C1, C2 and interpreter.

          I am leaning to make a new `GCInterface`, that would be implemented by each GC, and provides a `CollectorPolicy`, `CollectedHeap`, and `BarrierSet`, plus any new GC interface related things that are needed (e.g. `GCServicabilitySupport`, etc.).

          Testing
          -------

          This is purely refactoring. Everything that worked before needs to work afterwards.

          Documentation
          -------------

          Updated documentation is not needed because this is an internal refactoring.

          Performance
          -----------

          The performance must not regress due to this refactoring.

          Risks and Assumptions
          ---------------------

          A GC interface adds complexity. Currently stable and tested code in all collectors need to be changed. We hope that the benefit of clean and strict interface between GCs and the rest of HotSpot outweights the cost and risk of changes.

          We may not be able to implement it without harming performance.

          We may fail to identify and/or isolate all the touch points between GC and rest of the JVM.

          A first prototype would be implemented by focusing on code that directly includes `gc/cms` files, and abstract that out into GC interface code. This will allow us to identify obvious problems early on and address them.
          I suggest to integrate the majority of changes required for the GC interface at once, in order to get a fairly uniform treatment of all cases. Interpreter, C1, and C2 could be addressed in additional steps.

          A current snapshot of the work-in-progress can be found [here](http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.00/).


          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. The `GCInterface` needs to be extended to account for Shenandoah's read- and write-barriers though. Shenandoah requires read- and write-barriers in `BarrierSet` (for each of: runtime, interpreter, c1 and c2) plus the corresponding hooks all over the runtime, interpreter, c1 and c2. This change is very significant and would need to be discussed as part of the Shenandoah JEP. We added methods `read_barrier()` and `write_barrier()` and `obj_equals()` to `BarrierSet`, as well as all the corresponding hooks in the runtime, plus equivalent code generation in the interpreter, C1 and C2.


          [1]: http://openjdk.java.net/jeps/291
          [2]: http://openjdk.java.net/jeps/189
          Summary
          -------
          Improve the build-time isolation of different garbage collectors by designing a clean 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
          - Likewise, 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 is considered a success if GC implementations are mostly contained within source files in their `src/hotspot/share/gc/$NAME` and maybe `src/hotspot/cpu/share/vm/gc/$NAME` directories. Minimal code outside of those directories should include files from within those directories, and there should be very few GC-specific `if`-`else` branches. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Performance should not be negatively impacted due to this refactoring.

          Motivation
          ----------
          Currently, each garbage collector implementation 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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the build-time isolation of different garbage collectors by designing a clean 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
          - Likewise, 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 is considered a success if GC implementations are mostly contained within source files in their `src/hotspot/share/gc/$NAME` and maybe `src/hotspot/cpu/share/vm/gc/$NAME` directories. Minimal code outside of those directories should include files from within those directories, and there should be very few GC-specific `if`-`else` branches. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Performance should not be negatively impacted due to this refactoring.

          Motivation
          ----------
          Currently, each garbage collector implementation 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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the build-time isolation of different garbage collectors by designing 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 is considered a success if GC implementations are mostly contained within source files in their `src/hotspot/share/gc/$NAME` and maybe `src/hotspot/cpu/share/vm/gc/$NAME` directories. Minimal code outside of those directories should include files from within those directories, and there should be very few GC-specific `if`-`else` branches. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Performance should not be negatively impacted due to this refactoring.

          Motivation
          ----------
          Currently, each garbage collector implementation 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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the build-time isolation of different garbage collectors by designing 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 is considered a success if GC implementations are mostly contained within source files in their `src/hotspot/share/gc/$NAME` and maybe `src/hotspot/cpu/share/vm/gc/$NAME` directories. Minimal code outside of those directories should include files from within those directories, and there should be very few GC-specific `if`-`else` branches. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Performance should not be negatively impacted due to this refactoring.

          Motivation
          ----------
          Currently, each garbage collector implementation 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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the build-time isolation of different garbage collectors by designing 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 is considered a success if GC implementations are mostly contained within source files in their respective `src/hotspot/share/gc/$NAME` directory and maybe `src/hotspot/cpu/share/vm/gc/$NAME` directories. Minimal code outside of those directories should include files from within those directories, and there should be very few GC-specific `if`-`else` branches. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Performance should not be negatively impacted due to this refactoring.

          Motivation
          ----------
          Currently, each garbage collector implementation 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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the build-time isolation of different garbage collectors by designing 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 is considered a success if GC implementations are mostly contained within source files in their respective `src/hotspot/share/gc/$NAME` directory and maybe `src/hotspot/cpu/share/vm/gc/$NAME` directories. Minimal code outside of those directories should include files from within those directories, and there should be very few GC-specific `if`-`else` branches. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Performance should not be negatively impacted due to this refactoring.

          Motivation
          ----------
          Currently, each garbage collector implementation 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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the build-time isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Performance should not be negatively impacted due to this refactoring.

          Motivation
          ----------
          Currently, each garbage collector implementation 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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the build-time isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Performance should not be negatively impacted due to this refactoring.

          Motivation
          ----------
          Currently, each garbage collector implementation 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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the build-time isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Motivation
          ----------
          Currently, each garbage collector implementation 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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the build-time isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Motivation
          ----------
          Currently, each garbage collector implementation 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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Motivation
          ----------
          Currently, each garbage collector implementation 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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          Motivation
          ----------
          Currently, each garbage collector implementation 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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 the runtime, interpreter, C1 and C2 that needs changing.

          Description
          -----------
          The GC interface would be defined by the existing class `CollectedHeap` which 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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). This has recently come up with the proposal to deprecate the CMS collector ([JEP 291][1]). Similarily, the `INCLUDE_ALL_GCS` has long been a way to build the JVM with only the serial collector built-in.

          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 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 to 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 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 to 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 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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
          - VM argument initialization (what is currently scattered over `arguments.cpp`)
          - Setup of `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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
          - VM argument initialization
          - Setup of a `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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
          - VM argument initialization
          - Setup of a `MemoryService`, the related memory pools, memory managers, etc.
          - Code in the runtime, interpreter, C1 and C2 that currently has `if`-`else` switches to do GC specific things need to be changed to use the interface

          For implementations that are shared, the corresponding code should exist in a helper class, so that it can easily be called by the various GC implementations that need it. 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 `CardTable` 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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
          - VM argument initialization
          - 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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
          - VM argument initialization
          - 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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
          - HotSpot argument initialization
          - 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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
          - HotSpot argument initialization
          - 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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 more, 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. Running the standard regression test suites will suffice.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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. Running the standard regression test suites should suffice, no new tests has to be developed.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          ehelin Erik Helin made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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. Running the standard regression test suites should suffice, no new tests has to be developed.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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. Running the standard regression test suites should suffice, no new tests has to be developed.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring. Running industry standard benchmarks and verify that there are no regressions should suffice.

          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
          pliden Per Liden made changes -
          Reviewed By Per Liden [ pliden ]
          eosterlund Erik Österlund made changes -
          Reviewed By Per Liden [ pliden ] Erik Österlund [ eosterlund ]
          pliden Per Liden made changes -
          Reviewed By Erik Österlund [ eosterlund ] Erik Österlund, Per Liden [ eosterlund, pliden ]
          ehelin Erik Helin made changes -
          Reviewed By Erik Österlund, Per Liden [ eosterlund, pliden ] Erik Helin, Erik Österlund, Per Liden [ ehelin, eosterlund, pliden ]
          mikael Mikael Vidstedt made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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 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. Running the standard regression test suites should suffice, no new tests has to be developed.

          Documentation
          -------------
          Updated documentation is not needed because this is an HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring. Running industry standard benchmarks and verify that there are no regressions should suffice.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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. Running the standard regression test suites should suffice, no new tests have to be developed.

          Documentation
          -------------
          Updated documentation is not needed because this is HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring. Running industry standard benchmarks and verify that there are no regressions should suffice.

          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
          Hide
          mikael Mikael Vidstedt added a comment -
          This part (the way it's written) seems overly conservative:

          "Code for one GC implementation must only depend on code in src/hotspot/share/gc/shared and its own subdirectory (and of course code in the src/hotspot/share/memory directory)."

          The code should also be allowed to depend on various utility functionality, locks, logging, etc. as well?
          Show
          mikael Mikael Vidstedt added a comment - This part (the way it's written) seems overly conservative: "Code for one GC implementation must only depend on code in src/hotspot/share/gc/shared and its own subdirectory (and of course code in the src/hotspot/share/memory directory)." The code should also be allowed to depend on various utility functionality, locks, logging, etc. as well?
          rkennke Roman Kennke made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. Code for one GC implementation must only depend on code in `src/hotspot/share/gc/shared` and its own subdirectory (and of course code in the `src/hotspot/share/memory` directory).

          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. Running the standard regression test suites should suffice, no new tests have to be developed.

          Documentation
          -------------
          Updated documentation is not needed because this is HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring. Running industry standard benchmarks and verify that there are no regressions should suffice.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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.

          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. Running the standard regression test suites should suffice, no new tests have to be developed.

          Documentation
          -------------
          Updated documentation is not needed because this is HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring. Running industry standard benchmarks and verify that there are no regressions should suffice.

          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
          Hide
          ehelin Erik Helin added a comment -
          Thanks for your comment [~mikael], GC specific code can of course make use of "lower level" HotSpot functionality such as logging, locking, allocation etc. Roman has updated the "Success Metric" to more clearly describe that the goal is for _other_ HotSpot code to not contain GC specific code.
          Show
          ehelin Erik Helin added a comment - Thanks for your comment [~mikael], GC specific code can of course make use of "lower level" HotSpot functionality such as logging, locking, allocation etc. Roman has updated the "Success Metric" to more clearly describe that the goal is for _other_ HotSpot code to not contain GC specific code.
          mikael Mikael Vidstedt made changes -
          Reviewed By Erik Helin, Erik Österlund, Per Liden [ ehelin, eosterlund, pliden ] Erik Helin, Erik Österlund, Mikael Vidstedt, Per Liden [ ehelin, eosterlund, mikael, pliden ]
          mikael Mikael Vidstedt made changes -
          Endorsed By Mikael Vidstedt [ mikael ]
          rkennke Roman Kennke made changes -
          Status Candidate [ 10003 ] Proposed to Target [ 10004 ]
          Hide
          mr Mark Reinhold added a comment -
          This looks good, but could you please edit it so that it follows the JEP template (http://openjdk.java.net/jeps/2)? The template does not have "Documentation" or "Performance" sections. You don't really need to say anything about documentation anyway, and what you say in the Performance section is another success metric (do not regress benchmarks) plus a testing suggestion (continuous performance testing).
          Show
          mr Mark Reinhold added a comment - This looks good, but could you please edit it so that it follows the JEP template ( http://openjdk.java.net/jeps/2)? The template does not have "Documentation" or "Performance" sections. You don't really need to say anything about documentation anyway, and what you say in the Performance section is another success metric (do not regress benchmarks) plus a testing suggestion (continuous performance testing).
          rkennke Roman Kennke made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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.

          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. Running the standard regression test suites should suffice, no new tests have to be developed.

          Documentation
          -------------
          Updated documentation is not needed because this is HotSpot internal refactoring (it is not visible to a Java user).

          Performance
          -----------
          The performance should not regress due to this refactoring. Running industry standard benchmarks and verify that there are no regressions should suffice.

          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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. The performance should not regress due to this refactoring. Running industry standard benchmarks and verify that there are no regressions should suffice.


          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. 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
          rkennke Roman Kennke made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. The performance should not regress due to this refactoring. Running industry standard benchmarks and verify that there are no regressions should suffice.


          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. 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
          Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. The performance should not regress due to this refactoring. Continuous performance testing using industry standard benchmarks and verify that there are no regressions should suffice.


          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. 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
          Hide
          rkennke Roman Kennke added a comment -
          Mark: I took out the extra sections and added the performance part under success metrics. I hope it's ok now?
          Show
          rkennke Roman Kennke added a comment - Mark: I took out the extra sections and added the performance part under success metrics. I hope it's ok now?
          mr Mark Reinhold made changes -
          Description Summary
          -------
          Improve the source code isolation of different garbage collectors by designing 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 is 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. The performance should not regress due to this refactoring. Continuous performance testing using industry standard benchmarks and verify that there are no regressions should suffice.


          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. 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
          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
          Hide
          mr Mark Reinhold added a comment -
          Yes, thanks. For clarity I broke the metrics into a list. I'll send this out for review later today.
          Show
          mr Mark Reinhold added a comment - Yes, thanks. For clarity I broke the metrics into a list. I'll send this out for review later today.
          mr Mark Reinhold made changes -
          Labels jdk10-ptt-2017-11-02
          shade Aleksey Shipilev made changes -
          Reviewed By Erik Helin, Erik Österlund, Mikael Vidstedt, Per Liden [ ehelin, eosterlund, mikael, pliden ] Aleksey Shipilev, Erik Helin, Erik Österlund, Mikael Vidstedt, Per Liden [ shade, ehelin, eosterlund, mikael, pliden ]
          mr Mark Reinhold made changes -
          Status Proposed to Target [ 10004 ] Targeted [ 10005 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8189871 [ JDK-8189871 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8191564 [ JDK-8191564 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8191903 [ JDK-8191903 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8180194 [ JDK-8180194 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8191903 [ JDK-8191903 ]
          rkennke Roman Kennke made changes -
          Link This issue relates to JDK-8154343 [ JDK-8154343 ]
          rkennke Roman Kennke made changes -
          Status Targeted [ 10005 ] Integrated [ 10007 ]

            People

            • Assignee:
              rkennke Roman Kennke
              Reporter:
              rkennke Roman Kennke
              Owner:
              Roman Kennke
              Reviewed By:
              Aleksey Shipilev, Erik Helin, Erik Österlund, Mikael Vidstedt, Per Liden
              Endorsed By:
              Mikael Vidstedt
            • Votes:
              0 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

              • Created:
                Updated: