RFR: 8195129: System.load() fails to load from unicode paths [v2]

[David Holmes]

On Thu, 27 May 2021 16:28:14 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> 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