GC interface update

[Martijn Verburg]

Hi all,

Massive Bikeshed naming comment here - any reason why the interface isn't
named GarbageCollector?

Cheers,
Martijn

On 24 April 2017 at 07:37, Per Liden <per.liden at oracle.com> wrote:

> On 04/20/2017 02:29 PM, Roman Kennke wrote:
>
>> 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.
>>
>
> Yes, I'd like to keep CollectedHeap as the main interface, but I
> completely agree that CollectedHeap currently contains too much
> implementation stuff that we probably want to move out.
>
> cheers,
> Per
>
>
>> Cheers,
>> Roman
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170424/a03bd613/attachment.htm>