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

[Erik Österlund]

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
>