RFR: 8311207: Cleanup for Optimization for UUID.toString [v6]

[Roger Riggs]

On Sat, 1 Jul 2023 14:42:07 GMT, 温绍锦 <duke at openjdk.org> wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.toString"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ± 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ± 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ± 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ± 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
>> * cpu : aliyun yitian 710 (aarch64)
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ± 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ± 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ± 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ± 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ± 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ± 0.190  ops/us (-4.42%)
>
> 温绍锦 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code style

src/java.base/share/classes/java/util/HexDigits.java line 44:

> 42:      *       0 -> '00' -> ('0' << 8) | '0' -> 0x3030
> 43:      *       1 -> '01' -> ('0' << 8) | '1' -> 0x3130
> 44:      *       2 -> '02' -> ('0' << 8) | '2' -> 0x3230

The description of the array content does not need to be exhaustive; just sufficient to understand how it is indexed and the meaning of the values.

src/java.base/share/classes/java/util/HexDigits.java line 108:

> 106:      * Return a big-endian packed integer for the 4 ASCII bytes for an input unsigned 2-byte integer.
> 107:      * {@code b0} is the most significant byte and {@code b1} is the least significant byte.
> 108:      * The integer is passed byte-wise to allow reordering of execution.

The more natural API would be to pass the 16-bit value as an int (or short). Simplifying the callers.
Is there a significant performance difference?
The extraction of the 8-bit values could be done here instead of the caller and still allow hardware specific instruction optimization.

Also below, pass the 32-bit value as an int.

src/java.base/share/classes/java/util/HexDigits.java line 116:

> 114:     /**
> 115:      * Return a big-endian packed long for the 8 ASCII bytes for an input unsigned 4-byte integer.
> 116:      * {@code b0} is the most significant byte and {@code b4} is the least significant byte.

Typo "b4" -> "b3".

src/java.base/share/classes/java/util/UUID.java line 475:

> 473:         long msb = mostSigBits;
> 474:         byte[] buf = new byte[36];
> 475:         UNSAFE.putLongUnaligned(

I understood that since UUID was not used during startup, that using VarHandles is the preferred abstraction.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1255985815
PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1255966155
PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1255962869
PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1255980037