On Tue, 27 Jun 2023 14:13:48 GMT, Chen Liang <li...@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? >>> >>> 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