GC interface update

[Per Liden]

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
>