GC interface update
per.liden at oracle.com
Thu Apr 20 12:01:42 UTC 2017
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. 
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.
More information about the hotspot-gc-dev