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

[温绍锦]

On Thu, 29 Jun 2023 08:46:32 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:
> 
>   revert HexDigits.DIGITS private

> HexDigits.DIGITS



> I've read through [26f3a6a](https://github.com/openjdk/jdk/commit/26f3a6a5317718235bc3506f0a3e851001f43404) (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.

Good suggestion, it has been modified and submitted. now UUID#toString codeSize is 203, less than default FreqInlineSize 325,  It can be inline, and the performance is better than the previous version.

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

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