RFR: 8317951: Refactor loading of zip library to help resolve JDK-8315220 [v4]

Markus Grönlund mgronlun at openjdk.org
Thu Oct 26 12:26:33 UTC 2023


On Thu, 26 Oct 2023 12:11:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> So IIUC in the old code GZip_InitParam and GZip_Fully were lazily "resolved" at runtime and so no vm exit if anything went wrong. But now you are eagerly resolving them at the same time as all the other zip functions - which happens during VM init (or does it?**), so it would in fact make more sense to always do the vm_exit if something goes wrong.
> 
> ** Now I'm not at all sure the initialization will in fact happen at VM init time, in which case VM exit is not the right thing to do.

Right now what is there mirrors the existing behaviour. ClassLoader loads and resolves the method it requires. Should it fail, vm_exits. It does not do vm_exit if it fails to resolve the functions required only by HeapDumperCompression.

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

PR Comment: https://git.openjdk.org/jdk/pull/16149#issuecomment-1781016943


More information about the hotspot-runtime-dev mailing list