Request for review: JEP: GC Interface: Better isolation of GC implementations

[Roman Kennke]

Hi Erik,


> I think the overall approach you have outlined in the JEP is really 
> good, this is something I've wanted for a long time. We don't have
> to 
> get into all the gritty details to start with, but I have few
> initial 
> comments on your approach:
> 
> - why does the GCInterface need to include an implementation of
>    AdaptiveSizePolicy? Right now, the only common interface for all
> the
>    GC algorithms is CollectorPolicy. Why should it be required to
>    implement an AdaptiveSizePolicy?

I think I haven't given this particular piece of code not too much
thought. I saw it's currently in CollectedHeap::size_policy() and
'moved' that to GCInterface. I agree, it doesn't seem to be generally
used and should remain an implementation detail.

> - the part about MemoryService, the memory pools, etc. is great, that
>    code is a mess today.

Yup :-)

> - regarding your questions on where the barrier code for the JITs
> (C1,
>    C2) should be kept, I think I would prefer to have it in
>    src/share/vm/opto (for C2 code), but have it in a separate file. 

Ok, that sounds good to me.

> Have
>    you given any thought to JIT code other than the actual barriers?
> For
>    example passes in C2 that are only needed for a particular GC.

Yes and no. Shenandoah does require such passes, and it's kept in a
sepate file under src/share/vm/opto for now (in this case, called
shenandoahSupport.[hpp|cpp]. It's driven by various hooks in C2 though,
and I have not yet found a really great abstraction. 

> I also discussed your ideas around the BarrierSet with Erik
> Österlund, 
> our template guru :) I think Erik has few ideas in this area, but I
> will 
> let Erik describe his thoughts.

Ok, this will be very interesting! :-)

> On a more general note, is the patch at 
> http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.00/ up to
> date? 

I haven't continued work on it, from that point of view it's up-to-
date, but Hotspot has moved on since then... I'll update my workspace
and the patch accordingly, upload a new patch and let you know.

> If so, I will try to look through it and come back with some more 
> feedback. Furthermore, is there any way this could be implemented as
> a 
> series of patches (or as a branch in the jdk9/sandbox forest), to
> ease 
> reviewing?

Sure, series of patches or separate branch, both sound ok to me,
whatever you prefer. Series of patches would be easiest from my point
of view.

Cheers,
Roman