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

[David Holmes]

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.

Sorry  but you can't do this. Ironically this would "fix" a problem with DllMain and ForceTimeHighResolution, but in an incompatible way that could impact users (hence why it has never been fixed). But even before I saw that I disagreed with your premise that it is better to have one way to do this for dynamic and static builds: dynamic builds have been working just fine for decades with DllMain and there is no reason to change that and potentially break things in ways we can't imagine.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22793#pullrequestreview-2510449932