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

[Glavo]

On Tue, 27 Jun 2023 14:23:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>>> What I suggest is to prepare the array only once (in the static block as it is now), but have each class that use it encapsulate is own copy - obtained from clone(). Surely 256 shorts is not so large that we can't have two arrays?
>> 
>> I really wish we have frozen arrays, which are safely sharable like records. The closest we have right now is a final array with `@Stable`, which indicates array elements are lazy (any non-default value read can be treated as a constant by JIT); since this array is explicitly `@Stable final`, we can share it within the JDK like any other immutable objects.
>
> On second thought, we should be able to create a getter like
> 
> @ForceInline
> static short hex256(int byteValue) {
>     return HEX256[byteValue];
> }
> 
> and switch usages to that getter instead. This is a better approach than cloning the array and makes the array safe from modification by modules that get jdk.internal.util exports.

> Sadly, jdk.internal.util is exported to other modules so it does need to be looked at from an integrity perspective.

This is indeed a problem to consider.

Maybe we can move this array back into `HexDigits`. Then we create a new package `jdk.internal.digits` and move `Digits`, `DecimalDigits`, `HexDigits`, `OctalDigits` all into it.

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

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