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

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Aug 15 16:26:39 PDT 2012


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.

Thanks,
Vladimir

Vladimir Kozlov wrote:
> Christian Thalinger wrote:
>> On Aug 9, 2012, at 7:15 PM, Vladimir Kozlov 
>> <vladimir.kozlov at oracle.com> wrote:
>>
>>> Thanks, David
>>>
>>> pre_barrier() methods don't generate code for other GCs. But I forgot 
>>> to put UseG1GC guard around "new G1UnsafeGetObjSATBBarrierStub" in 
>>> c1_LIRGenerator.cpp.
>>
>> Did you update the webrev?  -- Chris
> 
> Not yet. I want to rewrite that code (which use 
> G1UnsafeGetObjSATBBarrierStub).
> 
> Vladimir
> 
>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 8/9/12 6:52 PM, David Holmes wrote:
>>>> On 10/08/2012 11:34 AM, Vladimir Kozlov wrote:
>>>>> http://cr.openjdk.java.net/~kvn/7190310/webrev
>>>>>
>>>>> 7190310: Inlining WeakReference.get(), and hoisting $referent may lead
>>>>> to non-terminating loops
>>>>>
>>>>> Add acquire membar after load from Reference.referent field to prevent
>>>>> commoning of loads across safepoint since GC can change its value.
>>>> Wow that was quick! :)
>>>>
>>>> My only comment (not being a compiler expert) is that it would 
>>>> appear that we are now inserting read barriers with all
>>>> GC's not just G1. What kind of impact will that have on performance 
>>>> under the other GC's?
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Thanks,
>>>>> Vladimir


More information about the hotspot-compiler-dev mailing list