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



Reply via email to