RFR: 8303814: getLastErrorString should avoid charset conversions

[Chris Plummer]

On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeliński <djelinski 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.

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

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