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

          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/
          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?
          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.
          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).
          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?
          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.

            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: