On Mon, 15 Nov 2021 17:32:04 GMT, Naoto Sato <na...@openjdk.org> wrote:
>> Please review the subject fix. In light of JEP400, Java runtime can/should >> start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Replace jnuEncoding in jni_util.c with UTF-8, if platform encoding is not > supported src/java.base/share/native/libjava/jni_util.c line 825: > 823: } > 824: (*env)->GetByteArrayRegion(env, hab, 0, len, (jbyte > *)result); > 825: result[len] = 0; /* NULL-terminate */ The change to newSizedStringJava is okay but I think the change to getStringBytes needs more eyes. Will it fall through to the code path sets it to FAST_UTF_8 during startup or does that happen later? If later then I assume there is a race with other threads that read jnuEncoding and potential for the JNI global ref to be freed from under their feet. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282