RFR(XS): JDK-8199780: SetMemory0 and CopyMemory0 in unsafe.cpp need to resolve their operands (original) (raw)

Roman Kennke rkennke at redhat.com
Tue Mar 20 10:36:27 UTC 2018

Same reason as splitting resolve -> resolve_for_read/resolve_for_write in other routines: being able to distinguish read and write access. Also, I'd rather be careful to put this stuff in central places that might over-cover it.

I've missed Unsafe_CopySwapMemory0, good find (has this been added recently?). I'll add Access calls there, and meditate a little bit how to put this into a more central place to avoid having to fix this for every code change in unsafe.cpp ;-)

Thanks, Roman

Is there a good reason why the Access<>::resolve is not performed inside of indexoopfromfieldoffsetlong instead of its callsites. For example, it looks like barriers are missing in UnsafeCopySwapMemory0, that you would get for free by putting the resolve barrier in the API used in this file for resolving addresses.

Thanks, /Erik On 2018-03-19 15:44, Roman Kennke wrote: SetMemory0 and CopyMemory0 in unsafe.cpp read and write from/to objects, and thus need to resolve their operands via Access::resolve() before accessing them.

Bug: https://bugs.openjdk.java.net/browse/JDK-8199780 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.00/ I'll say again that I'd prefer resolveforread() and resolveforwrite(), but for now the strong resolve() will suffice. ;-) Can I please get a review? Roman

More information about the hotspot-dev mailing list