GC interface update

[Kirk Pepperdine]

> On Apr 18, 2017, at 2:01 PM, Per Liden <per.liden at oracle.com> wrote:
> 
> Hi Roman,
> 
> On 2017-04-12 16:46, Roman Kennke wrote:
>> I spent some more time working on the GC interface prototype and wanted
>> to share it with you:
>> 
>> http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.02/
>> <http://cr.openjdk.java.net/%7Erkennke/gc-interface/webrev.02/>
>> 
>> Notable changes:
>> 
>> - It's now based on JDK10 (specifically,
>> http://hg.openjdk.java.net/jdk10/hs/hotspot changeset 12853:d276073fda85)
>> - I focused on better CMS isolation:
>>  - Most CMS specific stuff from GenCollectedHeap now resides in
>> specific subclass CMSHeap
>>  - Same for CardTableModRefBSForCTRS -> CMSBarrierSet
>>  - Factored everything related to always_do_update_barrier_set into CMS
>> subclasses
> 
> Good stuff. However, one thing I'm not quite comfortable with is the introduction of the GC class (and its sub classes). I don't quite see the purpose of this interface split-up between GC and CollectedHeap. I view CollectedHeap as _the_ interface (but yes, it needs some love), and as a result I think the the functions you've exposed in the GC class actually belongs in CollectedHeap.

I thought the name CollectedHeap implied the state of the heap after the collector has completed. What is the intent of CollectedHeap?

Kind regards,
Kirk