GC interface update

[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. A GC policy is in my mind 
inherently tied to the algorithms used by a specific GC. Attempts to 
expose some "general" policy is bound to fail and I think the current 
CollectorPolicy sort of shows that. The policy stuff is thankfully 
rarely used by non-GC code, which makes thing easier. I'd like to move 
the things that still makes sense in CollectorPolicy over to 
CollectedHeap and the rest should become internal to the specific GCs 
that need it. Various people have in the past done some good work to 
move us in this direction, but we're not here yet.

cheers,
Per

>
> -Aleksey
>
> [1]
> http://hg.openjdk.java.net/jdk10/sandbox/hotspot/file/c503fa980f8a/src/share/vm/gc/epsilon
>