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

[Thomas Stuefe]

On Tue, 14 Jan 2025 14:10:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Hmm, I don't think os::init is early enough.
> 
> Even if we accept that for static builds, we will not get the same debug coverage as for normal builds?
> 
> Static builds are still a very specialized target, and is unlikely to ever become a norm. I think for the use case, having certain restrictions compared to a normal, dynamic build is perfectly acceptable.

This is not just for windows, this is a general problem. Especially if static builds are the outliers, they will be rarely tested. So they will be prone to break. So they would benefit clearly from their initialization order closely mimicking whatever the dynamic library builds does, since that one is well tested. Therefore, I would not hide this issue under a windows-specific invocation somewhere inside of CreateJavaVM, but solve it more expressively. Therefore I think an official "PreInit" function would be a good idea, even if it is only fleshed on on Windows for now, and even if it is not exported as an own JNI invocation API from the libjvm dll.

These are just my five cent. I have little interest in the static build myself. This is just what I think I would do. I will approve the RFE, since it is good enough for its purpose, and leave it up to you if you want to spend more time on this.

> 
> Also, as long as we can't even build and start a static launcher on Windows, there is no way for us to test it to figure out if there are other startup issues at hand. Reading through the entire hotspot code base and try to look for potential candidates of startup ordering indeterminism does not sound like a feasible project to me.

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

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