RFR: JDK-8231085: C2/GC: Better GC-interface for expanding clone

Roman Kennke rkennke at redhat.com
Tue Sep 17 14:03:06 UTC 2019

Thanks, Erik!


> Hi Roman,
> Nice cleanup. This looks good to me. I agree it is more in line with how
> we have done other things.
> /Erik
> On 2019-09-17 11:40, Roman Kennke wrote:
>> The current GC-interface for inserting barriers after expanded clones is
>> rather rigid: it only allows to insert a barrier after the expanded
>> clone. It does, for example, not allow a barrier *before* the clone.
>> Also, a possible optimization would be to generate only a single call
>> for both the barrier and the actual clone, i.e. replace the whole
>> clone-expansion with a GC-specific call.
>> I propose that the expansion code for clone is fully owned by GC. This
>> is also in the spirit of other GC interfaces where the GC owns the whole
>> path. However, it requires relaxing visibility of some methods.
>> Jira issue:
>> https://bugs.openjdk.java.net/browse/JDK-8231085
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8231085/webrev.00/
>> Testing: tier1,2 locally without regressions
>> For an example how I intend to use it, look here (in
>> shenandoahBarrierSetC2.cpp):
>> http://cr.openjdk.java.net/~rkennke/JDK-8231086/webrev.00/
>> I intend to push this together with JDK-8231086 (otherwise Shenandoah
>> might be temporarily broken).
>> Can I please get a review?
>> Thanks,
>> Roman

More information about the hotspot-gc-dev mailing list