Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops

[Roland Westrelin]

> In C2 two reads (one outside a loop and an other inside) have the same inputs so IGVN replace second with dominating one outside the loop. I don't know if C1 does it now but nothing prevents from this in a future when someone decide to add more optimization into C1. On other hand it is unsafe reads (in HIR level), I doubt it will be allowed to common unsafe reads.

GVN in c1 operates on the HIR. Reference.get() is inlined in the HIR as an Intrinsic instruction node. Intrinsic instructions do not participate in GVN (something you find out by looking at the Intrinsic definition in c1_Instruction.hpp and checking whether it uses one of the HASHING{1,2,3} macro). So no Intrinsic instruction will be eliminated by GVN.

The other thing that could access the same field would be an UnsafeGetObject, right? GVN ignores this one as well.

When LIR is built, the UnsafeGetObject and the Reference.get() Intrinsic nodes become loads. No optimizations are then applied so no load will go away.

So to me, we are safe on the c1 side.

Roland.