RFR: JDK-8210656: Object equals abstraction for BarrierSetC2

[Roman Kennke]

Hi Erik,

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

Yes. We can already handle reasons that relate to 'stand-alone' barriers
(like dominating write-barriers and others). However, this one is
different because it relates to the *combination* of the two operands.
I.e. a property of operand A or B would affect barriers for both A *and*
B. This seems tricky to do after parsing. I guess we could look at CmpP,
check their operands for known-null, and elide the write-barriers then,
but this also means we need to check if the write-barriers haven't found
other uses in the meantime, etc). Overall, this seemed *much* more
hassle, whereas during parsing it comes quite naturally. See our impl:

https://paste.fedoraproject.org/paste/Hr~nKkm4HnZo3hmcw3Snnw

Roland: how hard/feasible would it be to do something like Erik
proposed? I.e. use the usual resolve() for obj-eq and elide barriers
later? It might have additional advantage (not sure) to catch cases
where type of an object becomes known-null later in the optimization
process?

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180913/adf37f57/signature.asc>