GC interface update

Roman Kennke rkennke at redhat.com
Thu Apr 20 11:42:33 UTC 2017

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170420/047e8f55/signature.asc>

More information about the hotspot-gc-dev mailing list