Integrated: 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.

This pull request has now been integrated.

Changeset: 1f365cc6
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f365cc6c75d355588b91e356e9f5dac5fb3555d
Stats:     53 lines in 5 files changed: 29 ins; 13 del; 11 mod

8346433: Cannot use DllMain in hotspot for static builds

Reviewed-by: dholmes, stuefe

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

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