RFR: 8346433: Cannot use DllMain in hotspot for static builds
Thomas Stuefe
stuefe at openjdk.org
Thu Dec 19 07:55:36 UTC 2024
On Tue, 17 Dec 2024 13:48:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use DllMain, for two reasons:
>
> 1) This is not called for statically linked libraries, and
> 2) There are multiple DllMain definitions throughout the JDK native libraries, causing name collisions.
>
> While it could have been possible to keep the DllMain function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds.
>
> The DllMain in hotspot is doing work both at DLL load time, and at DLL unload time. Let's go through them to see why this patch is safe.
>
> During DLL load time, the library handle is set, and the hi-res timer is initialized. The `pre_initialize` method from `WindowsDbgHelp` and `SymbolEngine` is called. These two are basically identical; both setup a critical section (a Windows mutex). However, this mutex is only used from a stack local guard object, which is allocated only when calls are made into these classes, which are not happening at bootstrapping time, so this shift in initialization time is harmless.
>
> That shift in time is also very small. The `DllMain` method is called by Windows when the DLL is loaded (by libjli), and the very first thing that JLI does after that is to call `JNI_CreateJavaVM`, which ends up calling `Threads::create_vm`, which calls `os::init` early on.
> In terms of this PR I would like to see explicit code for the static build (it could even call DllMain!) with zero perturbations to the initialization sequence of the dynamic build (no matter how safe they may appear) - please.
I agree with @dholmes-ora. Calling DllMain before invoking CreateJavaVM would be the least invasive method for solving these problems. We don't want to hunt initialization order bugs, especially since the early time windows before OS initialization are not that well tested.
src/hotspot/os/windows/os_windows.cpp line 4418:
> 4416: }
> 4417: WindowsDbgHelp::pre_initialize();
> 4418: SymbolEngine::pre_initialize();
As David has pointed out, this is too late. There is a reason we added this to DllMain - we need this initialized very early in case we crash before this point. We still will want useful hs-err files.
-------------
Changes requested by stuefe (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/22793#pullrequestreview-2513587788
PR Review Comment: https://git.openjdk.org/jdk/pull/22793#discussion_r1891295906
More information about the hotspot-runtime-dev
mailing list