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

[温绍锦]

On Sun, 25 Jun 2023 12:20:17 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:
> 
>   add jdk.util.HexDigits, sharing cache array across multiple classes, including :
>   java.lang.Long#fastUUID
>   java.util.HexDigits
>   java.lang.Long#toHexString(future)
>   java.lang.Integer#toHexString(future)
>   java.util.HexFormat(future)

i agree that backport is not the goal, but in the two packages java.util and java.lang share a cache array, it is more appropriate to put it in jdk.util.

> 



> > I don't think this is feasible, for this uses a new feature and hampers backport to jdk11.
> 
> I don't think affecting backports in general should be a reason to discourage new features from being used.
> 
> [wenshao at 4a3da4b](https://github.com/wenshao/jdk/commit/4a3da4b20fe0f7244c2c7bde3d9a0e2c8b91455a) is great for me.
> 
> Implementing some functions of UUID in `Long` is inherently illogical. Now that we can implement it efficiently in the `UUID` class, there's no reason why we shouldn't.

this implementation is cleaner and is my favorite.

the implementation of changing JavaLangAccess and Long for UUID.toString in the baseline is too intrusive.

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

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