RFR: JDK-8212603: Need to step over GC barriers in Node::eqv_uncast()

[Aleksey Shipilev]

On 10/17/2018 07:54 PM, Roman Kennke wrote:
> Node::eqv_uncast() checks if two nodes are equal (equivalent) behind
> casts. It's used in many places concerning lock elimination. The trouble
> is if the actual nodes are behind GC barriers, and we get the same node
> behind two different GC barrier nodes, this would return false negative.
> We have seen a bad case of this with Shenandoah, where lock elimination
> was subtly thrown off by this, which led to eliminated locks not
> re-locked properly during deoptimization.
> 
> I propose to also strip any possible GC barriers like this:
> 
> http://cr.openjdk.java.net/~rkennke/JDK-8212603/webrev.00/

Makes sense to me.

Does it deserve a better name? I don't know. There are "only" 25 usages of the method, and it can be
renamed without much fuzz? For example, Node::eqv_canonical? Node::eqv_final? Node::eqv_stripped?
Don't rush to rename it though :)

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20181017/36901abd/signature.asc>