GC interface update

Roman Kennke rkennke at redhat.com
Thu Apr 20 12:29:50 UTC 2017


Am 20.04.2017 um 14:01 schrieb Per Liden:
> On 2017-04-20 12:05, Aleksey Shipilev wrote:
>> On 04/20/2017 09:37 AM, Kirk Pepperdine wrote:
>>>> 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?
>>
>> No, CollectedHeap is the actual current GC interface. This is the
>> entry point to
>> GC as far as the rest of runtime is concerned, see e.g. CollectedHeap*
>> Universe::create_heap(), etc. Implementing CollectedHeap,
>> CollectorPolicy, and
>> BarrierSet are the bare minimum required for GC implementation today. [1]
> 
> Yep, and I'd like us to move towards tightening down the GC interface to
> basically be cleaned up versions of CollectedHeap and BarrierSet.
> 
> CollectorPolicy and some other things that class drags along, like
> AdaptiveSizePolicy, are way too collector specific and I don't think
> that should be exposed to the rest of the VM.

Right, I totally agree with this.

BTW, another reason for making a new GC interface class instead of
further bloating CollectedHeap as the central interface was that there
is way too much implementation stuff in CollectedHeap. Ideally, I'd like
to have a true interface with no or only trivial implementations for the
declared methods, and most importantly nothing that's only ever needed
by the GC itself (and never called by the runtime). But as I said, I'm
not against a serious refactoring and tightening-up of CollectedHeap
instead.

Cheers,
Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20170420/a2dc08c5/signature-0001.asc>


More information about the hotspot-gc-dev mailing list