JDK-5062728 : WIN64: VM should not use Vectored Exceptions
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0,5.0u5
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_2003,windows_xp
  • CPU: x86
  • Submitted: 2004-06-14
  • Updated: 2020-06-19
  • Resolved: 2004-12-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u8Fixed 6 b14Fixed
Related Reports
Duplicate :  
JDK-6320366 - Cannot use Structured Exception Handling on Windows x64 after JVMstarted
Relates :  
JDK-5040096 - Vtest/Vmark fail after 6 hrs run on windows2003 AMD 64bits with C2 flag
Relates :  
JDK-8247941 - Use Vectored Exception Handling on Windows
Relates :  
JDK-6354368 - Japanese IME crashes JVM on J2SE 1.5 for WindowsXP 64 bit edition
Description
Our 64 bit implementations of the JVM on Windows uses Vectored Exceptions.
This causes a conflict if the Windows OS code or native libraries want to
use Structured Exceptions. 

We recently worked around a bug that was caused by the fact that Windows
uses SEH in it's implementation of malloc.  They expected to get delivered
an exception in certain rare cases but we'd instead get notified in our
VEH and terminate the program with a fatal error.
We worked around this bug 5040096 by passing control to Windows
if an access violation is generated in NTDLL but this is not a 
perfect solution.

The main reason we chose VEH was the fact that Windows could not handle
dynamically generatred code during structured exception processing.
We assumed that noone else would want to get control on access violations.

The fix to this problem is to stop using Vectored Exceptions and register
all dynamically generated code with Microsoft RtlInstallFunctionCallback
or RtlAddFunctionTable APIs.  This will allow us to register our
exception handler for our code and allow Windows to dispatch exception
to native code that used try/except blocks.
###@###.### 11/3/04 16:54 GMT
Comments
SUGGESTED FIX Microsoft 64 bit Windows implementations no longer use frame based exception processing for delivering it's Structured Exceptions. C++ compilers instead must create function based data structures that are incorporated in the .EXE and .DLL file format that Windows uses to deliver its exceptions. Dynamically generated code can not use this facility since the load address and range of the generated code is not know at compile/link time. To work around this problem, the VM uses VectoredExceptions in 1.4.2 and 1.5 VM's on IA64 and AMD64. VectoredExceptions are similar to Unix signals. This mechanism works unless native code wishes to use structured exceptions. In this situation, our VectoredException handler takes control and the VM will generate an error wince the exception was not generatred by any VM code. A simple solution to this problem is to not allow native code to use SEH. This would work except for the fact that the Windows runtime libraries, use it to implement an accelerated malloc function. We worked around this bug in 1.5 by detecting exceptions in the NTDLL.DLL library but this leaves us open to other libraries in the OS doing the same thing. The real solution is to use an API new to Win64 that allows dynamically generated code to register it's code with the OS so Windows can determine which exception handler to call based on the IP address at the time of the exception. This mechanism is not very well documented and if implemented fully, would require us to register our prologue, frame setup, epilog and pseudo code to unwind stack frame for each method we compile. One further compilcation is that the unwind data structures are CPU dependent (IA64 and AMD64 are very different). Rather than complicate the code in the VM and reduce and compile time overhead, I decided to register all dynamically generated code in the VM as a single function. The unwind structure registered in the VM has no unwind code definitions and contains a single entry specifying the exception handle for this code region. NOTE THIS FIX IS AMD64 ONLY: The IA64 unwind information data is different from AMD64. I could not find any Microsoft documentation describing this. I found a reference to Intel docs but they did not match up with the MS docs. Since IA64 is currently not a planned release for 1.6, I decided to make an AMD64 only fix. Future work will have to be done to implement this bug fix for IA64. ###@###.### 11/3/04 16:54 GMT
03-11-2004
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: dragon
08-07-2004
EVALUATION The description says it all. ###@###.### 2004-06-14
14-06-2004