Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops
David Holmes
david.holmes at oracle.com
Thu Aug 16 03:46:38 PDT 2012
On 16/08/2012 7:08 PM, 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.
>
> insert_mem_bar(Op_MemBarCPUOrder) is not the same as __ membar_acquire(). __ membar_acquire() actually emits instructions on some platforms. Also, optimizations in c1 are performed at the HIR level. So adding the barrier at the LIR won't prevent any further optimization.
Not that I know much about C1 but the problem with C2 was purely a
compiler issue, hoisting the load. There should not be any need to emit
actual architectural level memory barriers here.
David
-----
> Can this problem actually happen with c1?
>
> Roland.
More information about the hotspot-compiler-dev
mailing list