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