RFR: 8199739: Use HeapAccess when loading oops from static fields in javaClasses.cpp
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Mon Mar 19 19:00:15 UTC 2018
I like Roman's version with static_field_base() the best. The reason I
wanted to keep static_field_addr and not have static_oop_addr was so
there is one function to find static fields and this would work with the
jvmci classes and with loading/storing primitives also. So I like the
consistent change that Roman has.
There's a subtlety that I haven't quite figured out here.
static_field_addr gets an address mirror+offset, so needs a load barrier
on this offset, then needs a load barrier on the offset of the
additional load (?)
http://cr.openjdk.java.net/~rkennke/JDK-8199739/webrev.00/src/hotspot/share/oops/instanceKlass.hpp.udiff.html
+ oop static_field_base() { return java_mirror(); }
Currently java_mirror() has no load_barriers because it's an OopHandle
in the ClassLoaderData. Will it with Shenandoah and ZGC (even before
concurrent class unloading?)
thanks,
Coleen
On 3/19/18 9:24 AM, Roman Kennke wrote:
> Hi Stefan,
>
> To be honest, I'd find it better to get rid of static_field_addr()
> altogether, and I am also not a fan of resolve(): it seems easy to just
> cover everything with it, but for Shenandoah it means to do a
> write-barrier, even when a read-barrier would suffice (which is
> cheaper). I recognize that none of the affected code is very performance
> sensitive, but if there is a cleaner solution, I'd go for this. What
> about this approach:
>
> http://cr.openjdk.java.net/~rkennke/JDK-8199739/webrev.00/
>
> ?
>
>
> Roman
>
>
>> Hi again,
>>
>> Seems like Coleen wanted me to solve this problem slightly differently.
>> She suggested that I add an Access<>::resolve barrier in static_field_addr:
>>
>> http://cr.openjdk.java.net/~stefank/8199739/webrev.03/
>>
>> This will probably solve the primitive access for Shenandoah. What do
>> you think?
>>
>> Thanks,
>> StefanK
>>
>> On 2018-03-19 12:29, Stefan Karlsson wrote:
>>> Hi Roman,
>>>
>>> On 2018-03-19 11:17, Roman Kennke wrote:
>>>> Hi Stefan,
>>>>
>>>> thank you!
>>>>
>>>> grepping for static_field_addr() yields some more places that'd need
>>>> similar treatment:
>>>>
>>>> jlong java_lang_ref_SoftReference::clock()
>>>> void java_lang_ref_SoftReference::set_clock(jlong value)
>>>>
>>>> Maybe cover them as well? Or I'll file a separate issue. Your call.
>>> This seems like primitive accesses, I'll be happy to leave those to
>>> you. ;)
>>>
>>> Thanks,
>>> StefanK
>>>
>>>> Thanks, Roman
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> Kim and Roman commented that my patch doesn't work with Shenandoah.
>>>>> Here's an updated version:
>>>>> http://cr.openjdk.java.net/~stefank/8199739/webrev.02/
>>>>>
>>>>> Thanks,
>>>>> StefanK
>>>>>
>>>>> On 2018-03-16 15:39, Stefan Karlsson wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Please review this patch to use HeapAccess<>::oop_load instead of
>>>>>> oopDesc::load_decode_heap_oop when loading oops from static fields in
>>>>>> javaClasses.cpp:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~stefank/8199739/webrev.01/
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8199739
>>>>>>
>>>>>> It's necessary to use HeapAccess<>::oop_load to inject load barriers
>>>>>> for GCs that need them.
>>>>>>
>>>>>> Thanks,
>>>>>> StefanK
>>>>
>
More information about the hotspot-dev
mailing list