Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]
On Fri, 28 May 2021 05:47:11 GMT, David Holmes wrote: > The core-libs folks have the experience/expertise with these character > encoding issues so I will defer to them. Naoto has agreed to look at this. - PR: https://git.openjdk.java.net/jdk/pull/4169
Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]
On Thu, 27 May 2021 16:28:14 GMT, Maxim Kartashev
wrote:
>> src/hotspot/os/windows/os_windows.cpp line 1541:
>>
>>> 1539: void * os::dll_load(const char *utf8_name, char *ebuf, int ebuflen) {
>>> 1540: LPWSTR utf16_name = NULL;
>>> 1541: errno_t err = convert_UTF8_to_UTF16(utf8_name, &utf16_name);
>>
>> Do you have any figures on the cost of this additional conversion in
>> relation to startup time?
>>
>> I'm already concerned to see that we have to perform each conversion twice
>> via MultiByteToWideChar/WideCharToMultiByte, once to get the size and then
>> to actually get the characters! This seems potentially very inefficient.
>
> I measured time spend converting the library path name relative to the
> overall time of a (successful) `os::dll_load()` call. It varies between a
> fraction of a percent to ~3% (see below for the actual data from a `release`
> build). I'll defer to your expertise wrt to these numbers.
>
> What can be done here (without changing os::dll_load() API) is to have a
> "fast path" for ascii-only path names, in which case no conversion is
> necessary, and a "slow path" for all the rest. This will complicate things a
> bit, but not by much, I believe. I am certainly willing to give that a try.
> Let me know what do you think.
>
>
>
> ./build/windows-x86_64-server-release/images/jdk/bin/java -jar
> ./build/windows-x86_64-server-fastdebug/images/jdk/demo/jfc/SwingSet2/SwingSet2.jar
> 0.050% for
> C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\jimage.dll
> 2.273% for
> C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.dll
> 0.177% for
> C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\net.dll
> 0.541% for
> C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\nio.dll
> 0.359% for
> C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\zip.dll
> 3.186% for
> C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\jimage.dll
> 0.075% for
> C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\awt.dll
> 0.232% for
> C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\freetype.dll
> 0.136% for
> C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\fontmanager.dll
> 0.170% for
> C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\javajpeg.dll
The core-libs folks have the experience/expertise with these character encoding
issues so I will defer to them. But someone should run this through our startup
benchmarks to see if it makes a difference.
Thanks,
David
-
PR: https://git.openjdk.java.net/jdk/pull/4169
Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]
On Thu, 27 May 2021 05:13:44 GMT, David Holmes wrote:
>> Maxim Kartashev has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull request
>> contains one new commit since the last revision:
>>
>> 8195129: System.load() fails to load from unicode paths
>
> src/hotspot/os/windows/os_windows.cpp line 1541:
>
>> 1539: void * os::dll_load(const char *utf8_name, char *ebuf, int ebuflen) {
>> 1540: LPWSTR utf16_name = NULL;
>> 1541: errno_t err = convert_UTF8_to_UTF16(utf8_name, &utf16_name);
>
> Do you have any figures on the cost of this additional conversion in relation
> to startup time?
>
> I'm already concerned to see that we have to perform each conversion twice
> via MultiByteToWideChar/WideCharToMultiByte, once to get the size and then to
> actually get the characters! This seems potentially very inefficient.
I measured time spend converting the library path name relative to the overall
time of a (successful) `os::dll_load()` call. It varies between a fraction of a
percent to ~3% (see below for the actual data from a `release` build). I'll
defer to your expertise wrt to these numbers.
What can be done here (without changing os::dll_load() API) is to have a "fast
path" for ascii-only path names, in which case no conversion is necessary, and
a "slow path" for all the rest. This will complicate things a bit, but not by
much, I believe. I am certainly willing to give that a try. Let me know what do
you think.
./build/windows-x86_64-server-release/images/jdk/bin/java -jar
./build/windows-x86_64-server-fastdebug/images/jdk/demo/jfc/SwingSet2/SwingSet2.jar
0.050% for
C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\jimage.dll
2.273% for
C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.dll
0.177% for
C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\net.dll
0.541% for
C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\nio.dll
0.359% for
C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\zip.dll
3.186% for
C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\jimage.dll
0.075% for
C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\awt.dll
0.232% for
C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\freetype.dll
0.136% for
C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\fontmanager.dll
0.170% for
C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\javajpeg.dll
-
PR: https://git.openjdk.java.net/jdk/pull/4169
Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]
On Thu, 27 May 2021 05:18:50 GMT, David Holmes wrote:
>> Maxim Kartashev has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull request
>> contains one new commit since the last revision:
>>
>> 8195129: System.load() fails to load from unicode paths
>
> test/hotspot/jtreg/runtime/jni/loadLibraryUnicode/LoadLibraryUnicode.java
> line 48:
>
>> 46: } else {
>> 47: throw new Error("Unsupported OS");
>> 48: }
>
> Please use the test library function `Platform.sharedLibraryExt()` to get the
> library file extension.
Thanks for the suggestion. Rewrote this piece.
(Side note: since the libraries' prefix differs between platforms also, it'd be
nice to have something like `Platform.sharedLibraryName(name)`; this is the way
all the code that uses `Platform.sharedLibraryExt()` is structured anyway. But
I guess it's best not to conflate things).
-
PR: https://git.openjdk.java.net/jdk/pull/4169
Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]
On Thu, 27 May 2021 04:23:16 GMT, David Holmes wrote: >> Maxim Kartashev has refreshed the contents of this pull request, and >> previous commits have been removed. The incremental views will show >> differences compared to the previous content of the PR. The pull request >> contains one new commit since the last revision: >> >> 8195129: System.load() fails to load from unicode paths > > src/hotspot/os/windows/os_windows.cpp line 1462: > >> 1460: const int flag_source_str_is_null_terminated = -1; >> 1461: const int flag_estimate_chars_count = 0; >> 1462: int utf16_chars_count_estimated = >> MultiByteToWideChar(source_encoding, > > Your local naming style is somewhat excessive. You could just comment the > values of the flags when you pass them eg: > > MultiByteToWideChar(source_encoding, > MB_ERR_INVALID_CHARS, >source_str, >-1, //source is null-terminated > NULL, // no output buffer > 0); // calculate required buffer size > > Or you could just add a comment before the call: > > // Perform a dummy conversion so that we can get the required size of the > buffer to > // allocate. The source is null-terminated. > > Trying to document parameter semantics by variable naming doesn't work in my > opinion - at some point if you want to know you have to RTFM for the API. > > And utf16_len is perfectly adequate for the returned size. Fair enough. Corrected. - PR: https://git.openjdk.java.net/jdk/pull/4169
Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]
On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev wrote: >> Character strings within JVM are produced and consumed in several formats. >> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() >> or dlopen()) consume strings also in UTF8. On Windows, however, the >> situation is far less simple: some new(er) APIs expect UTF16 (wide-character >> strings), some older APIs can only work with strings in a "platform" format, >> where not all UTF8 characters can be represented; which ones can depends on >> the current "code page". >> >> This commit switches the Windows version of native library loading code to >> using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use >> of various string formats in the surrounding code. >> >> Namely, exception messages are made to consume strings explicitly in the >> UTF8 format, while logging functions (that end up using legacy Windows API) >> are made to consume "platform" strings in most cases. One exception is >> `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, >> which can, of course, be fixed, but was considered not worth the additional >> code (NB: this isn't a new bug). >> >> The test runs in a separate JVM in order to make NIO happy about non-ASCII >> characters in the file name; tests are executed with LC_ALL=C and that >> doesn't let NIO work with non-ASCII file names even on Linux or MacOS. >> >> Tested by running `test/hotspot/jtreg:tier1` on Linux and >> `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` >> jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran >> on those platforms as well. >> >> Results from Linux: >> >> Test summary >> == >>TEST TOTAL PASS FAIL ERROR >> >>jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 >> >> == >> TEST SUCCESS >> >> >> Building target 'run-test-only' in configuration >> 'linux-x86_64-server-release' >> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', >> will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 >> >> >> Results from Windows 10: >> >> Test summary >> == >>TEST TOTAL PASS FAIL ERROR >>jtreg:test/hotspot/jtreg/runtime746 746 0 0 >> == >> TEST SUCCESS >> Finished building target 'run-test-only' in configuration >> 'windows-x86_64-server-fastdebug' >> >> >> Building target 'run-test-only' in configuration >> 'windows-x86_64-server-fastdebug' >> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 > > Maxim Kartashev has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared to the previous content of the PR. The pull request contains one new > commit since the last revision: > > 8195129: System.load() fails to load from unicode paths Hi Maxim, Overall this seems okay. I've focused mainly on the hotspot parts, including the test. A few minor changes requested. I do have some concerns about the impact on startup though and the efficiency of the conversion routines. Thanks, David src/hotspot/os/windows/os_windows.cpp line 1462: > 1460: const int flag_source_str_is_null_terminated = -1; > 1461: const int flag_estimate_chars_count = 0; > 1462: int utf16_chars_count_estimated = MultiByteToWideChar(source_encoding, Your local naming style is somewhat excessive. You could just comment the values of the flags when you pass them eg: MultiByteToWideChar(source_encoding, MB_ERR_INVALID_CHARS, source_str, -1, //source is null-terminated NULL, // no output buffer 0); // calculate required buffer size Or you could just add a comment before the call: // Perform a dummy conversion so that we can get the required size of the buffer to // allocate. The source is null-terminated. Trying to document parameter semantics by variable naming doesn't work in my opinion - at some point if you want to know you have to RTFM for the API. And utf16_len is perfectly adequate for the returned size. src/hotspot/os/windows/os_windows.cpp line 1541: > 1539: void * os::dll_load(co
Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]
On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev wrote: >> Character strings within JVM are produced and consumed in several formats. >> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() >> or dlopen()) consume strings also in UTF8. On Windows, however, the >> situation is far less simple: some new(er) APIs expect UTF16 (wide-character >> strings), some older APIs can only work with strings in a "platform" format, >> where not all UTF8 characters can be represented; which ones can depends on >> the current "code page". >> >> This commit switches the Windows version of native library loading code to >> using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use >> of various string formats in the surrounding code. >> >> Namely, exception messages are made to consume strings explicitly in the >> UTF8 format, while logging functions (that end up using legacy Windows API) >> are made to consume "platform" strings in most cases. One exception is >> `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, >> which can, of course, be fixed, but was considered not worth the additional >> code (NB: this isn't a new bug). >> >> The test runs in a separate JVM in order to make NIO happy about non-ASCII >> characters in the file name; tests are executed with LC_ALL=C and that >> doesn't let NIO work with non-ASCII file names even on Linux or MacOS. >> >> Tested by running `test/hotspot/jtreg:tier1` on Linux and >> `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` >> jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran >> on those platforms as well. >> >> Results from Linux: >> >> Test summary >> == >>TEST TOTAL PASS FAIL ERROR >> >>jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 >> >> == >> TEST SUCCESS >> >> >> Building target 'run-test-only' in configuration >> 'linux-x86_64-server-release' >> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', >> will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 >> >> >> Results from Windows 10: >> >> Test summary >> == >>TEST TOTAL PASS FAIL ERROR >>jtreg:test/hotspot/jtreg/runtime746 746 0 0 >> == >> TEST SUCCESS >> Finished building target 'run-test-only' in configuration >> 'windows-x86_64-server-fastdebug' >> >> >> Building target 'run-test-only' in configuration >> 'windows-x86_64-server-fastdebug' >> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 > > Maxim Kartashev has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared to the previous content of the PR. The pull request contains one new > commit since the last revision: > > 8195129: System.load() fails to load from unicode paths Hi Maxim, Please don't force-push changes once you have opened a PR and review has commenced as it messes up the history and comments. Just push each commit directly. The final integration will squash everything into one clean commit. Thanks, David - PR: https://git.openjdk.java.net/jdk/pull/4169
Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]
On 27/05/2021 6:59 am, Gerard Ziemski wrote:
On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev
wrote:
I tried verifying the test on **macOS** by running:
`jtreg -nr -va -jdk:./build/macosx-x86_64-server-fastdebug/images/jdk
test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`
and I get:
`TEST RESULT: Error. Use -nativepath to specify the location of native code`
I looked at the test and thought it was handling loading the native lib on its
own, without the test needing to set **nativepath** explicitly. What am I
doing wrong?
You always have to set nativepath explicitly for jtreg. The test then
reads the property that jtreg defines using the value of -nativepath:
String testNativePath =
LoadLibraryUnicodeTest.getSystemProperty("test.nativepath");
Cheers,
David
-
-
PR: https://git.openjdk.java.net/jdk/pull/4169
Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]
On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev wrote: >> Character strings within JVM are produced and consumed in several formats. >> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() >> or dlopen()) consume strings also in UTF8. On Windows, however, the >> situation is far less simple: some new(er) APIs expect UTF16 (wide-character >> strings), some older APIs can only work with strings in a "platform" format, >> where not all UTF8 characters can be represented; which ones can depends on >> the current "code page". >> >> This commit switches the Windows version of native library loading code to >> using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use >> of various string formats in the surrounding code. >> >> Namely, exception messages are made to consume strings explicitly in the >> UTF8 format, while logging functions (that end up using legacy Windows API) >> are made to consume "platform" strings in most cases. One exception is >> `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, >> which can, of course, be fixed, but was considered not worth the additional >> code (NB: this isn't a new bug). >> >> The test runs in a separate JVM in order to make NIO happy about non-ASCII >> characters in the file name; tests are executed with LC_ALL=C and that >> doesn't let NIO work with non-ASCII file names even on Linux or MacOS. >> >> Tested by running `test/hotspot/jtreg:tier1` on Linux and >> `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` >> jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran >> on those platforms as well. >> >> Results from Linux: >> >> Test summary >> == >>TEST TOTAL PASS FAIL ERROR >> >>jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 >> >> == >> TEST SUCCESS >> >> >> Building target 'run-test-only' in configuration >> 'linux-x86_64-server-release' >> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', >> will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 >> >> >> Results from Windows 10: >> >> Test summary >> == >>TEST TOTAL PASS FAIL ERROR >>jtreg:test/hotspot/jtreg/runtime746 746 0 0 >> == >> TEST SUCCESS >> Finished building target 'run-test-only' in configuration >> 'windows-x86_64-server-fastdebug' >> >> >> Building target 'run-test-only' in configuration >> 'windows-x86_64-server-fastdebug' >> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 > > Maxim Kartashev has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared to the previous content of the PR. The pull request contains one new > commit since the last revision: > > 8195129: System.load() fails to load from unicode paths I tried verifying the test on **macOS** by running: `jtreg -nr -va -jdk:./build/macosx-x86_64-server-fastdebug/images/jdk test/hotspot/jtreg/runtime/jni/loadLibraryUnicode` and I get: `TEST RESULT: Error. Use -nativepath to specify the location of native code` I looked at the test and thought it was handling loading the native lib on its own, without the test needing to set **nativepath** explicitly. What am I doing wrong? - PR: https://git.openjdk.java.net/jdk/pull/4169
Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]
> Character strings within JVM are produced and consumed in several formats. > Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() > or dlopen()) consume strings also in UTF8. On Windows, however, the situation > is far less simple: some new(er) APIs expect UTF16 (wide-character strings), > some older APIs can only work with strings in a "platform" format, where not > all UTF8 characters can be represented; which ones can depends on the current > "code page". > > This commit switches the Windows version of native library loading code to > using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use > of various string formats in the surrounding code. > > Namely, exception messages are made to consume strings explicitly in the UTF8 > format, while logging functions (that end up using legacy Windows API) are > made to consume "platform" strings in most cases. One exception is > `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, > which can, of course, be fixed, but was considered not worth the additional > code (NB: this isn't a new bug). > > The test runs in a separate JVM in order to make NIO happy about non-ASCII > characters in the file name; tests are executed with LC_ALL=C and that > doesn't let NIO work with non-ASCII file names even on Linux or MacOS. > > Tested by running `test/hotspot/jtreg:tier1` on Linux and > `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` > jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran > on those platforms as well. > > Results from Linux: > > Test summary > == >TEST TOTAL PASS FAIL ERROR > >jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 > > == > TEST SUCCESS > > > Building target 'run-test-only' in configuration 'linux-x86_64-server-release' > Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', > will run: > * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode > > Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' > Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java > Test results: passed: 1 > > > Results from Windows 10: > > Test summary > == >TEST TOTAL PASS FAIL ERROR >jtreg:test/hotspot/jtreg/runtime746 746 0 0 > == > TEST SUCCESS > Finished building target 'run-test-only' in configuration > 'windows-x86_64-server-fastdebug' > > > Building target 'run-test-only' in configuration > 'windows-x86_64-server-fastdebug' > Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: > * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode > > Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' > Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java > Test results: passed: 1 Maxim Kartashev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8195129: System.load() fails to load from unicode paths - Changes: - all: https://git.openjdk.java.net/jdk/pull/4169/files - new: https://git.openjdk.java.net/jdk/pull/4169/files/265f7907..fe661dff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=00-01 Stats: 55 lines in 3 files changed: 24 ins; 1 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/4169.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4169/head:pull/4169 PR: https://git.openjdk.java.net/jdk/pull/4169
