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

[Vladimir Kozlov]

Thank you, Roland

On 8/16/12 2:08 AM, Roland Westrelin wrote:
> Hi Vladimir,
>
>> I updated webrev:
>>
>> http://cr.openjdk.java.net/~kvn/7190310/webrev.01
>>
>> During testing I found several problem with code for unsafe.getObject() intrinsic code in both: C1 and C2. I moved some checks in C1 from G1UnsafeGetObjSATBBarrierStub stub into shared code and also added static klass analysis to avoid generation of G1/membar code if klass is not Reference or Object. In C2 I hit bad graph problem because If node's projections in insert_pre_barrier() were not put on IGVN worklist.
>>
>> I added jtreg tests (thanks to John Cuthbertson for unsafe test which I extended).
>>
>> Tested with CTW and Kitchensink with C1, C2, tiered.
>
> The c1 side doesn't look right to me.

It is nice to have C1 expert in our group :)

>
> insert_mem_bar(Op_MemBarCPUOrder) is not the same as __ membar_acquire(). __ membar_acquire() actually emits instructions on some platforms.

I was not able to find in C1 a something which separates reads and prevents GVN to common them but does not generate 
actual asm code.

> Also, optimizations in c1 are performed at the HIR level. So adding the barrier at the LIR won't prevent any further optimization.

So how I do that?

>
> Can this problem actually happen with c1?

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.

Thanks,
Vladimir

>
> Roland.