RFR (S) 8238289: Use _byteswap_ functions to implement Bytes::swap_uX on Windows
david.holmes at oracle.com
Mon Apr 6 07:16:29 UTC 2020
On 6/04/2020 4:00 pm, Schmelter, Ralf wrote:
> 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
Ha ha! Of course.
> Best regards,
> -----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:
>> 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:
> 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! ???
>> 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,
More information about the hotspot-runtime-dev