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

Daniel Fuchs dfuchs at openjdk.org
Tue Jun 27 13:13:25 UTC 2023


On Tue, 27 Jun 2023 11:27:18 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:
> 
>   fix UUID.java import, rename jdk.util.HexDigits to jdk.util.Hex256 and make private constructor.

src/java.base/share/classes/jdk/internal/util/Hex256.java line 38:

> 36: 
> 37:     @Stable
> 38:     public static final short[] DIGITS;

It's a bit smelly to have a public static field of type array.
Static analysers are likely to flag this.
It would be better to make the field private and have a public static method that returns DIGITS.clone() - then each class that needs it (and if I'm not mistaken there are only two) could encapsulate its own private copy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243711721


More information about the core-libs-dev mailing list