On Mon, 28 Jun 2021 03:25:09 GMT, Yi Yang <yy...@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
