RFR JDK-8141491: Unaligned memory access in Bits.c
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.
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