RFR: 8346433: Cannot use DllMain in hotspot for static builds

[Magnus Ihse Bursie]

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.

Also, is it just ForceTimeHighResolution you are worried about, or is it also the pre_initialize calls? If you are okay with moving them, we can reduce the size of DllMain, and hence the amount of duplicated code.

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

PR Comment: https://git.openjdk.org/jdk/pull/22793#issuecomment-2550019383