Peek through barriers in Node::eqv_uncast()

[Aleksey Shipilev]

On 10/17/2018 11:53 AM, Roman Kennke wrote:
> Node::eqv_uncast() seems to be used a lot in the code paths that deal
> with eliminating locks, mostly to match lock nodes with their
> corresponding unlock nodes, and a few other things. This seems to be a
> bit fragile: if the unlock ever consumes a different input than the lock
> node, e.g. because they end up with different barrier nodes on the same
> object, then this will throw off lock elimination. I suspect that this
> is what's happening with lucene.
> 
> I am not sure yet how lock and unlock could end up with different
> barriers on same object, and I'm not actually 100% sure it fixes the
> problem, therefore this RFR is preliminary to get reviews on it, and
> maybe some extra testing (lucene is running fairly long, I'm midway
> through my 2nd run only).
> 
> The proposed fix is:
> http://cr.openjdk.java.net/~rkennke/c2-eqv/webrev.00/

Ugh. Interesting find, and looks upstreamable.

It looks that change in callnode.cpp is not needed, because Node::eqv_uncast would do the same?

Anyhow, there is ";;" to clean up.

-Aleksey