RFR(XS): JDK-8199780: SetMemory0 and CopyMemory0 in unsafe.cpp need to resolve their operands
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 ;-)
> Is there a good reason why the Access<>::resolve is not performed inside
> of index_oop_from_field_offset_long instead of its callsites. For
> example, it looks like barriers are missing in Unsafe_CopySwapMemory0,
> that you would get for free by putting the resolve barrier in the API
> used in this file for resolving addresses.
> 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.
>> I'll say again that I'd prefer resolve_for_read() and
>> resolve_for_write(), but for now the strong resolve() will suffice. ;-)
>> Can I please get a review?
More information about the hotspot-dev