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