RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows

David Holmes david.holmes at oracle.com
Wed Mar 11 20:43:08 UTC 2015

Hi Thomas,

I'm not really familiar with Windows SEH. Won't this break custom 
launchers that already provide their own try/catch around Crate_JavaVM ?

(And I hate seeing the win32 ifdefs in the shared code :( ).


On 12/03/2015 1:40 AM, Thomas Stüfe wrote:
> Hi all,
> please review this smallish change:
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8074860/webrev.01/webrev/
> bug:  https://bugs.openjdk.java.net/browse/JDK-8074860
> This change adds SEH guards around JNI_CreateJavaVM(). Without the change,
> on Windows, the VM initialization runs without crash protection: crashes
> will terminate VM immediately without writing an error log; also, any
> techniques relying on signals will not work, e.g. SafeFetch().
> This was partly solved before on a case-by-case base by wrapping code
> sections which may crash in their own __try/__except wrappers - e.g. CPU
> feature probing.
> The change guards the whole of JNI_CreateJavaVM invocation in
> __try/__except. Unfortunately, for that to compile, I needed to introduce a
> wrapper around JNI_CreateJavaVM and move the whole of JNI_CreateJavaVM to a
> new function "JNI_CreateJavaVM_inner".
> This fix also gets rid of various workarounds which were used before to
> guard code sections.
> Thanks for reviewing!
> Oh, on a side note: I tried to figure out if threads which are attached
> from the outside via JNI AttachCurrentThread() are in any way guarded with
> SEH protection. Newly created threads are guarded because they run thru
> java_start() in os_windows.cpp, which adds SEH guards to all frames below.
> But for attached threads, I did not find any SEH guards - or maybe I am
> blind? What does that mean for java code running inside attached threads?
> Regards,
> Thomas Stuefe

More information about the hotspot-runtime-dev mailing list