Request for review: JEP: GC Interface: Better isolation of GC implementations
erik.helin at oracle.com
Thu Nov 17 14:08:39 UTC 2016
On 11/15/2016 07:02 PM, Roman Kennke wrote:
> Hi all,
> No comments on that one?
sorry, I must have missed your email the first time, thanks for sending
out a reminder.
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?
- the part about MemoryService, the memory pools, etc. is great, that
code is a mess today.
- 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. 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.
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.
On a more general note, is the patch at
http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.00/ up to date?
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
> I'd like to move it to 'submitted' if nobody objects.
> Am Dienstag, den 16.08.2016, 19:37 +0200 schrieb Roman Kennke:
>> Hi all,
>> I would like to ask for your opinion on the JEP draft:
>> It was born out of the discussion around JEP 291: Deprecate the
>> Concurrent Mark Sweep (CMS) Garbage Collector, and the development of
>> the Shenandoah GC, both of which would benefit greatly from better GC
>> Best regards, Roman
More information about the hotspot-gc-dev