RFR: 8269384: Determine native byte order for StringUTF16 via ByteOrder

[David Holmes]

On Mon, 28 Jun 2021 03:25:09 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Prefer using ByteOrder to compute byte order for StringUTF16 to determining byte order by native method StringUTF16.isBigEndian.
>
> Hi Aleksey, do you have a concrete issue/discussion about bootstrapping problems? I don't see it because I can build JDK and passes tier1 tests w/o problems. But I admit this may cause potential problems. In order to reduce potential risks, how about changing the class initialization orders, i.e. initialize UUnsafeConstants_klas earlier, which seems reasonable:
> 
> 
> void Threads::initialize_java_lang_classes(JavaThread* main_thread, TRAPS) {
>   TraceTime timer("Initialize java.lang classes", TRACETIME_LOG(Info, startuptime));
> 
>   if (EagerXrunInit && Arguments::init_libraries_at_startup()) {
>     create_vm_init_libraries();
>   }
> 
> +#ifdef ASSERT
> +  InstanceKlass *k = vmClasses::UnsafeConstants_klass();
> +  assert(k->is_not_initialized(), "UnsafeConstants should not already be initialized");
> +#endif
> +
> +  // initialize the hardware-specific constants needed by Unsafe
> +  initialize_class(vmSymbols::jdk_internal_misc_UnsafeConstants(), CHECK);
> +  jdk_internal_misc_UnsafeConstants::set_unsafe_constants();
> 
>   initialize_class(vmSymbols::java_lang_String(), CHECK);
> 
>   // Inject CompactStrings value after the static initializers for String ran.
>   java_lang_String::set_compact_strings(CompactStrings);
>   ...

@kelthuzadx , if you want to discuss initialization order changes please take this to hotspot-runtime-dev. Simply building okay and running a few tests can never validate a change in VM initialization order - there are a lot of subtleties involved, platform differences, affect of different flags, etc etc. Thanks @adinn for the details on this specific proposal - I agree that we neither want to make UnsafeConstants unable to use String, nor expose it for use by String.

Backing up a step what is the motivation for change here? Is there something wrong with the way String currently does this? Or is it just that it seemed on the surface that you could skip the native call and "just use Byteorder"?

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

PR: https://git.openjdk.java.net/jdk/pull/4596