RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v30]

[Alan Bateman]

On Tue, 27 Jun 2023 17:44:23 GMT, 温绍锦 <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ±  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ± 1023.532  ops/ms
>
> 温绍锦 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused import, and fix comment

I've read through 26f3a6a5 (iteration 29) and it mostly looks okay.

It's good to see the UUID code removed from Long.

It's unfortunate that UUID is directly accessing HexDigits.DIGITS but at least its in the same package and the array is accessed more widely. If there were frozen arrays then this would be better. Have you measured using an accessor method to access the array elements rather than accessing the array directly?

Somewhat subjective but I find the new comment in Digits a bit confusing, particularly "In the byte[] encoded in LATIN1" as a byte[] is just bytes and I think you want to say a String encoding as LATIN1 in a byte[]. Maybe drop this and the reference to jdk.internal.util.ByteArray.

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

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1612579949