RFR (S) 8238289: Use _byteswap_ functions to implement Bytes::swap_uX on Windows

[Schmelter, Ralf]

Hi David,

> They are described as "Reverses the order of bytes in an integer." but 
> then has the examples:
>
> byteswap of 102030405060708 = 807060504030201
> cbyteswap of 1020304 = 4030201
>
> which is not byte swapping! ???

yeah, the output of the example confused me too, since it seems it swaps the nibbles. But with the missing leading 0 printed too it makes it easier to spot  it does in fact swapped the bytes:

byteswap of 0102030405060708 = 0807060504030201
cbyteswap of 01020304 = 04030201

Best regards,
Ralf

-----Original Message-----
From: David Holmes <david.holmes at oracle.com> 
Sent: Monday, April 6, 2020 1:55 AM
To: Schmelter, Ralf <ralf.schmelter at sap.com>; hotspot-runtime-dev at openjdk.java.net runtime <hotspot-runtime-dev at openjdk.java.net>
Subject: Re: RFR (S) 8238289: Use _byteswap_ functions to implement Bytes::swap_uX on Windows

Hi Ralf,

On 3/04/2020 6:40 pm, Schmelter, Ralf wrote:
> Hi,
> 
> can you please review this change. It uses the VS compiler intrinsics to implement byte order swapping for 16, 32 and 64 bit types. For most other platforms we already used the platform specific calls to do this.
> 
> bugreport: https://bugs.openjdk.java.net/browse/JDK-8238289
> webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8238289/webrev.0/

On the surface this looks good.

My only concern is that the docs for those functions seem incorrect:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/byteswap-uint64-byteswap-ulong-byteswap-ushort?view=vs-2019

They are described as "Reverses the order of bytes in an integer." but 
then has the examples:

byteswap of 102030405060708 = 807060504030201
byteswap of 1020304 = 4030201

which is not byte swapping! ???

Cheers,
David

> As a consequence of this change the size of the server.dll increased by ~ 7kB for a release build. This was not expected, since the code needed for a implementation of the byte swap calls itself was much smaller now. In the end I've traced it down to more inlining being done in the JFR code.
> 
> Best regards,
> Ralf
>