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 <a...@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
