GC interface update

[Kirk Pepperdine]

> On Apr 20, 2017, at 1:42 PM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> Am 18.04.2017 um 14:01 schrieb Per Liden:
>> 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.
> 
> Well yes, I was thinking about that too. CollectedHeap currently is
> _the_ central interface. However, I already found it quite crammed.
> Plus, there are other 'interfaces' that make up the 'GC interface', e.g.
> BarrierSet, CollectorPolicy, and some other stuff (that I listed in the
> JEP), and I thought I'd rather create a new hub-kindof interface that
> manages all those sub-interfaces. I am not against putting all this into
> CollectedHeap (and hopefully, cleaning up CollectedHeap too). I found it
> cleaner the way I did it though.

+1 on separating out BarrierSet and CollectorPolicy.

Regards,
Kirk