RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast path for UTF-8

Xueming Shen xueming.shen at oracle.com
Fri Jun 16 13:42:32 UTC 2017


On Jun 15, 2017, at 3:35 PM, Claes Redestad <claes.redestad at oracle.com> wrote:

> On 2017-06-15 18:50, Alan Bateman wrote:
>> On 15/06/2017 17:26, Chris Hegarty wrote:
>> :
>> Claes,
>> 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 ... -nativepath:build/macosx-x86_64-normal-server-release/support/test/jdk/jtreg/native/lib
>> 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
test configuration.

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
this approach.

New webrev:



More information about the core-libs-dev mailing list