RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast path for UTF-8
claes.redestad at oracle.com
Thu Jun 15 22:35:54 UTC 2017
On 2017-06-15 18:50, Alan Bateman wrote:
> On 15/06/2017 17:26, Chris Hegarty wrote:
>> This is the first test in the core area that will now use a test
>> specific native library, which will need to be built ( by the build
>> system, which it does ), and pointed to when executing jtreg
>> from the command line, e.g.
>> jtreg ...
>> I think this may be ok, but some folk will need to get used to
>> adding this option to their jtreg runs. Either that, or move the
>> test to a separate group / target.
> One thing to mention is `jtreg -k:!native ..` if you need to skip the
> native tests.
If you don't mind I'd like to move ahead with the test
configuration as-is, and then if there's a pressing need
to split the jdk_lang test group into a native and non-native
part that can be done as a follow-up. As there seems
there's a simple workaround in case a test system needs
time to adapt this doesn't seem too unreasonable, no?
I've been using the new run-test target to test this locally:
make run-test TEST=jdk/test/java/lang/String/nativeEncoding
Very convenient, and it of course emits the full command
line for reruns if something goes wrong.
On a different note I finally found out how to allow specifying
different runs with native tests:
@run main/othervm/native ...
By running this with -Xcheck:jni I found a couple of benign
issues (passed wrong arguments to
ReleasePrimitiveArrayCritical in both jni_util.c and the test,
and triggered a capacity warning at one place in pre-existing
code). I fixed these and added -Xcheck:jni to the default
Now it turns out setting -Dsun.jnu.encoding actually breaks
things in subtle ways (seems the native code reads the implicit
property, which is determined by LANG/LC_ALL before it gets
set by the provided flag). I've verified the test passes locally
for some different LANG+LC_ALL values, but can't figure out
how to express that in the test. I think we can lean on having
test systems with different default locales set, and leave it to
the future to - if possible - improve coverage.
Finally, Chris Hegarty pointed out that we could use the
@Native annotation to expose constants to JNI code (as
generated #defines), which saves us the trouble of
maintaining this assumption as a test. Since there doesn't
seem to be any drawbacks to this then I went ahead with
More information about the core-libs-dev