RFR JDK-8141491: Unaligned memory access in Bits.c

Mikael Vidstedt mikael.vidstedt at oracle.com
Thu Jan 28 01:13:57 UTC 2016


Just an FYI:

I'm working on moving all of this to the Hotspot Copy class and bridging 
to it via jdk.internal.misc.Unsafe, removing Bits.c altogether. The 
implementation is working, and the preliminary performance numbers beat 
the pants off of any of the suggested Bits.c implementations (yay!).

I'm currently in the progress of getting some unit tests in place for it 
all to make sure it covers all the corner cases and then I'll run some 
real benchmarks to see if it actually lives up to the expectations.

Cheers,
Mikael

On 2016-01-26 11:13, John Rose wrote:
> On Jan 26, 2016, at 11:08 AM, Andrew Haley <aph at redhat.com> wrote:
>> On 01/26/2016 07:04 PM, John Rose wrote:
>>> Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic.
>>> IMO that's a better starting point than memcpy.  Perhaps it can be
>>> given an additional parameter (or overloading) to specify a swap size.
>> OK, but conjoint_memory_atomic doesn't guarantee that destination
>> words won't be torn if their source is misaligned: in fact it
>> guarantees that they will will be.
> That's a good point, and argues for a new function with the
> stronger guarantee.  Actually, it would be perfectly reasonable
> to strengthen the guarantee on the existing function.  I don't
> think anyone will care about the slight performance change,
> especially since it is probably favorable.  Since it's Unsafe,
> they are not supposed to care, either.
>
> — John



More information about the hotspot-dev mailing list