Peek through barriers in Node::eqv_uncast()

[Roman Kennke]

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

Yes, indeed. But let's spin it a bit in Shenandoah first, shall we?
In-fact, I want to run the lucene suite a few more times before even
pushing it, each run takes 1-2hours so maybe until EOD? This frickin bug
tends to be very spurious.

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

Right. Leftover from earlier attempts.

http://cr.openjdk.java.net/~rkennke/c2-eqv/webrev.01/

Roman