On Tue, 27 Jun 2023 14:13:48 GMT, Chen Liang <[email protected]> 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?
>>>
>>> The point is that it doesn't make any sense, so I don't feel like we should
>>> pay anything for it.
>>
>> Daniel makes a good point. Sadly, jdk.internal.util is exported to other
>> modules so it does need to be looked at from an integrity perspective.
>
>> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243840048
