[8u] RFR 8141491: Unaligned memory access in Bits.c

[Mikael Vidstedt]

This seems reasonable to me in order to avoid adding to the API surface.

I slightly dislike the duplication of the MAX_OBJECT_SIZE/field_offset_to_byte_offset/assert_field_offset_sane from unsafe.cpp, but it’s small enough that I’m okay with it.

All in all, thumbs up from me.

Cheers,
Mikael

> On Nov 30, 2018, at 7:10 PM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> Adding hotspot-runtime-dev as this will require discussion there.
> 
> As context, David Buck is back porting Mikael's changes for JDK-8141491 to 8u. The backport is trying to avoid adding public methods to sun.misc.Unsafe as those methods are not present in sun.misc.Unsafe of newer releases (we don't want to add methods to JDK 8's Unsafe, have people find them, use them, and then show up with pitchforks because they do not exist in newer releases). The approach on the table now is to add the JVM_CopySwapMemory and have it be called by a JNI method. JVM_* functions are JDK internal/undocumented/unsupported but it needs to be discussed and reviewed here.
> 
> -Alan
> 
> 
> On 30/11/2018 06:58, David Buck wrote:
>> Hi Alan and Mikael!
>> 
>> Thank you for the review. I'm sorry it took so long to respond.
>> 
>> Based on advice received from Alan off-line, I have reworked the backport:
>> 
>> http://cr.openjdk.java.net/~dbuck/8141491_jdk8_ver01/
>> 
>> The native portion of the copySwapMemory implementation has been moved from Unsafe into jvm.cpp (JNI_* and friends). A few minor inline helper functions and a macro have been copied from the Unsafe implementation to facilitate. Normally I consider redundancy a code smell, but any attempt to factor that out of Unsafe felt unnatural and inelegant. The Java portion of copySwapMemory's implementation has been included in java.nio.Bits as that is the only place it is used. Otherwise, there should not be anything too surprising.
>> 
>> Any feedback would be greatly appreciated.
>> 
>> Cheers,
>> -Buck
>