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

[温绍锦]

On Mon, 26 Jun 2023 09:57:31 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:
> 
>   use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1

> I'm looking through [[6b61a71](https://github.com/openjdk/jdk/commit/6b61a715caeeb586d5480a3a70f90bd1811d1335)], update 24.
> 
> Moving fastUUID out of Long is good.
> 
> UUID::toString can use StandardCharsets. ISO_8859_1, no need to use sun.nio.cs code here.
> 
> The list of imports in java.util.UUID is a bit messy now, can you clean this up.
> 
> It's confusing to have java.util.HexDigits and jdk.internal.util.HexDigits. It also creates an inconsistency with DecimalDigits and OctalDigits as the latter encapsulate their arrays. I assume you've done this to allow sharing of the 256 element array. I don't object to move the array to a supporting class but it needs to be renamed and the class description replaced as it is not a Digits implementation. Adding a private constructor would help make it clear that it should not be instantiated.

very good suggestion, i have modified it according to your suggestion.

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

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