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

[Mikael Vidstedt]

I've finally found some time to return to this and have a new version of 
the patch which looks more promising:

http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/

This uses memcpy to read/write the native data and the preliminary 
benchmark numbers on linux/x64 shows the expected performance. I'll work 
on verifying that it doesn't impact other platforms negatively over the 
next days/weeks.

Btw, I also played around with implementing it in pure Java, but there 
are some issues getting C2 to correctly vectorize the loop given the 
native data accesses, so the native code seems to be needed for now.

Cheers,
Mikael

On 2015-11-25 13:32, Mikael Vidstedt wrote:
>
> Have you looked anything at the performance of the generated code? As 
> you may have seen I was playing around with an alternative 
> implementation[1] which has the benefit of being pure C++ without 
> compiler specific hints. That said, when I did some initial 
> benchmarking of that it did seem like the performance impact was 
> significant. I didn't have time to look at more in detail why, and 
> will not have time to return to that until late next week earliest. It 
> would be interesting to understand what type of performance you see 
> with your patch.
>
> Cheers,
> Mikael
>
>
> [1] 
> http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.01/webrev/jdk.patch
>
> On 2015-11-25 11:42, Coleen Phillimore wrote:
>> Sending to core-libs mailing list.
>>
>> On 11/25/15 2:19 PM, Alexander Smundak wrote:
>>> Please take a look at
>>> http://cr.openjdk.java.net/~asmundak/8141491/jdk/webrev.00
>>> that fixes the problem.
>>>
>>> It utilizes the ability of some (GCC and Clang) to declare data
>>> alignment explicitly.
>>> I have verified it works on x86_64 Linux by running
>>> jdk/test/java/nio/Buffer/Basic.java test
>>>
>>> I need a sponsor.
>>>
>>> Sasha
>>
>