On Mon, 18 Mar 2024 14:09:09 GMT, Per Minborg <pminb...@openjdk.org> wrote:
> This PR proposes to remove the native method `StringUTF16::isBigEndian` and > its corresponding C implementation and instead rely on the > `jdk.internal.misc.Unsafe::isBigEndian` method. > > This PR passes tier1-3 tests. > Initialization order ```java -Xlog:class+init -XX:-CompactStrings -version```: Before: [0.015s][info][class,init] 71 Initializing 'java/lang/StringUTF16' (0x000000ff00063a20) by thread "main" [0.015s][info][class,init] 72 Initializing 'jdk/internal/util/ArraysSupport' (0x000000ff00063c20) by thread "main" [0.015s][info][class,init] 73 Initializing 'jdk/internal/misc/Unsafe' (0x000000ff00050de0) by thread "main" After: [0.018s][info][class,init] 71 Initializing 'java/lang/StringUTF16' (0x0000000400063a30) by thread "main" [0.018s][info][class,init] 72 Initializing 'jdk/internal/misc/Unsafe' (0x0000000400050de0) by thread "main" [0.018s][info][class,init] 73 Initializing 'jdk/internal/util/ArraysSupport' (0x0000000400063c30) by thread "main" Seems the order only changes subtly. > Unsafe was added 2015, a few weeks before the explicit C code was added. This > might indicate the previous solution was deliberate or it might be the case, > the new method was not known by the author at the time. `sun.misc.Unsafe::isBigEndian` has existed longer, and was removed when `jdk.internal.misc.Unsafe` was added. `StringUTF16::isBigEndian` was added by JEP 254 by a group of people who I believe would have been well aware of its existence. It doesn't seem that having `StringUTF16` have a `<clinit>` dependency on `Unsafe` is problematic today, though. Perhaps `sun.misc.Unsafe` did more weird things back in 2015. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18348#issuecomment-2005200875
