RFR: 8303814: getLastErrorString should avoid charset conversions

[Daniel Jeliński]

On Wed, 8 Mar 2023 23:23:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
>> 
>> Other changes include:
>> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
>> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
>> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
>> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
>> - `getLastErrorString` is no longer exported by libjava.
>> 
>> Tier1-3 tests continue to pass.
>> 
>> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
>> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"不知道这样的主机。"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.
>
> We don't have a test for the SA changes you made. The best way to test it is with clhsdb. Run the following against a JVM pid:
> 
> `$ jhsdb clhsdb --pid <pid>`
> 
> Use "jstack -v" to get a native pc from a frame, and then try `disassemble` on the address. It most likely will produce an exception since it can't find hsdis, which is actually what we want to be testing in this case:
> 
> 
> hsdb> disassemble 0x00007f38b371fca0
> Error: sun.jvm.hotspot.debugger.DebuggerException: hsdis-amd64.so: cannot open shared object file: No such file or directory
> 
> 
> You'll need to test separately on Windows and any unix platform.

Thanks @plummercj for the instructions. Here's the results:
Linux, with this change applied:

hsdb> disassemble 0x00007f3484558da0
Error: sun.jvm.hotspot.debugger.DebuggerException: hsdis-amd64.so: cannot open shared object file: No such file or directory

Windows, EN, with the change:

hsdb> disassemble 0x00000107d4dae0c6
Error: sun.jvm.hotspot.debugger.DebuggerException: The specified module could not be found

Windows, misconfigured CN, without the change:

hsdb> disassemble 0x00000200d60de0b4
Error: sun.jvm.hotspot.debugger.DebuggerException: ?????????

Windows, misconfigured CN, with the change:

hsdb> disassemble 0x000001fab996e0b4
Error: sun.jvm.hotspot.debugger.DebuggerException: 找不到指定的模块。

(note: I had to run `chcp 65001` in the console, otherwise the exception would still display incorrectly)

-------------

PR: https://git.openjdk.org/jdk/pull/12922