RFR: 8199739: Use HeapAccess when loading oops from static fields in javaClasses.cpp (original) (raw)

Roman Kennke rkennke at redhat.com
Mon Mar 19 13:24:27 UTC 2018

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 staticfieldaddr: 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 staticfieldaddr() yields some more places that'd need similar treatment: jlong javalangrefSoftReference::clock() void javalangrefSoftReference::setclock(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<>::oopload instead of oopDesc::loaddecodeheapoop 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<>::oopload to inject load barriers for GCs that need them. Thanks, StefanK

More information about the hotspot-dev mailing list