RFR: 8191564: Refactor GC related servicability code into GC specific subclasses
rkennke at redhat.com
Tue Nov 21 21:37:40 UTC 2017
I had some off-band discussions with Erik Helin and re-did most of the
- The GC interface now resides in CollectedHeap, specifically the two
methods memory_managers() and memory_pools(), and is implemented in the
various concrete subclasses.
- Both methods return (by value) a GrowableArray<GCMemoryManager*> and
GrowableArray<MemoryPool> respectively. Returning a stack-allocated
GrowableArray seemed least complicated (avoid explicit cleanup of
short-lived array object), and most future-proof, e.g. currently there
is an implicit expectation to get 2 GCMemoryManagers, even though some
GCs don't necessarily have two. The API allows for easy extension of the
I think this requires reviews from both the GC and Serviceability team.
> Currently, there's lots of GC specific code sprinkled over
> src/hotspot/share/services. This change introduces a GC interface for
> that, and moves all GC specific code to their respective
> src/hotspot/share/gc directory.
> Testing: hotspot_gc and hotspot_serviceability, none showed regressions
> Built minimal and server without regressions
> What do you think?
More information about the hotspot-gc-dev