On Mon, 18 Mar 2024 22:51:55 GMT, Claes Redestad <redes...@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. Thanks for the clarifications @cl4es! ------------- PR Comment: https://git.openjdk.org/jdk/pull/18348#issuecomment-2006338283
