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

[Roman Kennke]

Thanks, Erik!

Roman


> 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
>>
>