[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: [8u] RFR 8141491: Unaligned memory access in Bits.c
From:       Alan Bateman <Alan.Bateman () oracle ! com>
Date:       2018-11-30 9:10:38
Message-ID: 8cf98c3b-20ac-f65e-081e-57fe1be2c27b () oracle ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]