RFR: JDK-8210656: Object equals abstraction for BarrierSetC2

[Erik Österlund]

Hi Roman,

Interesting. So semantically, this is cmp(resolve(a), resolve(b)), but 
you have circumstances in which the barriers are unnecessary and can be 
elided. Any of them having null in their type is one reason, but I 
suppose there are surely other reasons as well (such as finding 
dominating write barriers).

I see two different approaches for this barrier elision:
1) Elide it during parsing (as you propose)
2) Elide it during Optimize (which I think conceptually looks like a 
natural fit)

I originally proposed a function on BarrierSetC2 that I think I called 
optimize_barriers() or something like that. The idea was to use this 
hook to let GC barrier code shave off pointless (not to be confused with 
useless) barriers that can be removed. Roland thought that this seemed 
too specific to ZGC to warrant a general API, and I agreed, because 
indeed only ZGC used this hook at the time. This is today 
ZBarrierSetC2::find_dominating_barriers which is called straight from 
Optimize.

I wonder if it would make sense to re-instate that hook. Then you could 
use the existing resolve() barriers during parsing, and leave barrier 
elision tricks (null checks included, plus other tricks you might have 
up your sleeve) to Optimize. For example, you might be able to walk your 
list of barriers and disconnect these pointless barriers. What do you think?

Thanks,
/Erik

On 2018-09-12 22:11, Roman Kennke wrote:
> This introduces an abstraction to deal with object equality in
> BarrierSetC2. This is needed by GCs that can have different copies of
> same objects alive like Shenandoah.
>
> The approach chosen here is slightly different than we did in e.g.
> BarrierSetAssembler and the runtime Access API: instead of owning the
> whole equality, it only provides a resolve-like method to resolve the
> operands to stable values. The reason for doing this is that it's easier
> to do this way in intrinsics if those barriers are detached from the
> actual CmpP. This is because the barriers create new memory states, and
> we'd have to create memphis around those things, which is considerably
> more complex.
>
> I chose to add a new resolve_for_obj_equals(a, b) method instead of
> using two calls to resolve(a); resolve(b); because this allows for
> optimization: if any of a or b is known to be NULL, we can elide
> barriers for both. This is not possible to do with two independent
> resolve() calls.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8210656
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8210656/webrev.00/
>
> Testing: passes hotspot/jtreg:tier1
>
> What do you think about this?
>
> Thanks,
> Roman
>