RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

[Roman Kennke]

I had some off-band discussions with Erik Helin and re-did most of the 
changeset:
- 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 
situation.

http://cr.openjdk.java.net/~rkennke/8191564/webrev.01/

I think this requires reviews from both the GC and Serviceability team.

Roman


> 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.
> 
> http://cr.openjdk.java.net/~rkennke/8191564/webrev.00/ 
> <http://cr.openjdk.java.net/%7Erkennke/8191564/webrev.00/>
> 
> Testing: hotspot_gc and hotspot_serviceability, none showed regressions
> 
> Built minimal and server without regressions
> 
> What do you think?
> 
> Roman
> 
>