On Tue, 25 Jan 2022 10:29:48 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
> I'm curious, under what circumstances would, before > https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the LoadLibrary > in imageDecompressor.cpp? Did this ever work? Was there ever a scenario where > the JVM was not involved and hence the zip.dll was not loaded already? > > For me, the code looks good unless I miss a scenario where we don't have the > JVM loaded already at this point. Thanks for review. Before 8237750, the zip library is always loaded so jimage just get the handle of the loaded zip by calling . After that, zip is loaded at need, so if jvm does not use zip, it will not be loaded. Unfortunately, it does not realize that jimage is using this zip, so it failed to get the handle. But there exists a case, if the zip is in PATH, the following fix 8244495 used LoadLibrary("zip.dll") for a rescue. If zip.dll is not in PATH, the call still failed to load zip. This is the current issue. So far, if user loaded zip from native code before jimage code is executed ( I could not image a scenario how it can happen), the GetModuleHandle("zip.dll") may return the handle to it, but it does not surely it is for the "zip.dll" --- if multiple instances exist, the returned handle is not guaranteed the one you want. With this change, if user loads zip from native code (with different version), JVM does not sense that, it will still load zip from $JDK or $JRE, and jimage still uses handle returned from JVM. The only case is JVM failed to load zip library: if (_zip_handle == NULL) { vm_exit_during_initialization("Unable to load zip library", path); } You cannot make any progress on the failure. ------------- PR: https://git.openjdk.java.net/jdk/pull/7206
