RFR(S): Use Vectored Exception Handling on Windows

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Mon Jun 29 12:19:04 UTC 2020

FWIW, I too remember working with transforming from using SEH to VEH in 
the JRockit JVM. Unfortunately, this was years ago, and I don't remember 
any specifics. But my memory is quite rosy, so I think we got much more 
of a success story by going from SEH to VEH, than the picture that has 
been painted here.

Let me know if it would be of sufficient worth for you if I manage to 
dig up some old code, and see if we did things differently to have VEH 
work out for us. (Or maybe we did just not test it enough to find the 
issues ;-))


On 2020-06-21 14:55, Thomas Stüfe wrote:
> Hi,
> We at SAP had used VEH in our own Windows Itanium port and I dimly remember
> it being a source of problems. That is many years ago and I realize that it
> is not worth much, but it makes me bit apprehensive of this change.
> The main problem I see is that this will be an observable change in
> behavior.
> We currently use SEH, so our error handler is guaranteed to be invoked only
> for exceptions from within our own code. With VEH we now follow the Unix
> way of things and suddenly our error handler becomes a global resource.
> We will suddenly be invoked for crashes outside the VM, e.g. in foreign
> launcher code atop of us or in non-java side threads, which will generate
> whole new classes of hs-err files for crashes the VM is not responsible
> for. Which are then perceived as VM crashes and sent to us vendors instead
> of going to the right people. This is the way it works on Unix today, and
> it is a constant annoyance and increases our support workload.
> We also may introduce new problems since suddenly we interfere with
> application exception handling. At the very least, we have to think up a
> scheme for signal chaining (both ways: VM->foreign code and foreign
> code->VM). For the first, we probably need some form of libjsig preloading,
> or some other way to divert signal handler instalment. That would also need
> cooperation from the application programmers and/or operators.
> Matters are even more complicated, since foreign code may use SEH instead
> of VEH, so what happens if a JNI library below me wants to use SEH, does
> that still work?
> I feel this should not be rushed. Even considered "brittle" SEH has served
> us well, I do not recall many problems in the past aside from having to add
> the occasional __try/__except. Are there actual bugs we have to solve?
> Lastly, personally I always found SEH quite a neat concept, and one of the
> few places where Windows was superior to Unix :)
> Thanks, Thomas
> On Fri, Jun 19, 2020 at 5:23 PM Ludovic Henry <luhenry at microsoft.com> wrote:
>> Hello,
>> First, some context and definitions:
>> - when talking about exception here, I'm talking about Win32 exception
>> which are equivalent to signals on Linux and other Unix, I am _not_ talking
>> about Java exceptions.
>> - an explanation of an _exception filter_ can be found at
>> https://docs.microsoft.com/en-us/cpp/cpp/writing-an-exception-filter?view=vs-2019.
>> There is only a limited concept of that in Java with type-based exception
>> filter (ex: `try { ... } catch (IOException ioe) { ... } catch (Throwable
>> t) { ... }`).
>> - in Win32, there exist two exception handling mechanism:
>>    - Structured Exception Handling: the historical one, based on `__try {}
>> __except (...) {}`
>>    - Vectored Exception Handling: introduced in Windows XP / Windows Server
>> 2003, much more similar to signals on Linux
>> These exception handling mechanisms are used to catch any exceptions like
>> Access Violation, Stack Overflow, Divide by Zero, Overflow, and more. These
>> exceptions are equivalent to signal on Linux and are then core to many
>> mechanisms in the OpenJDK.
>> Today, the OpenJDK uses Structured Exception Handling to catch such
>> exceptions, creating several requirements. First, all code that might
>> trigger an exception on purpose (like a Access Violation / SIGSEGV in the
>> arraycopy stub), needs to be wrapped up in a __try / __except. Because it's
>> not feasible to wrap every single instance of such code, these __try /
>> __except are put at the top-level most function of any thread started by
>> the runtime. Second, for code generated by Hotspot, `RtlAddFunctionTable`
>> is used to simulate the use of __try / __except for a specific code area.
>> This function needs platform specific code with the generation of  a
>> trampoline that calls the exception filter declared in the runtime. It's
>> also meant to be used as a one to one mapping with try / catch in user
>> code, and not as a "catch all the exceptions in this code area". Third,
>> Structured Exception Handling expects to be able to unwind the stack.
>> However, because Hotspot doesn't guarantee the usage of the
>> platform-specific ABI internally, the platform-specific unwinder might
>> break. Hotspot's usage of `RtlAddFunctionTable` for the code cache relies
>> on the assumption that Structured Exception Handling never tries to unwind
>> the stack (which it would fail to do because of the different ABI) before
>> calling the registered exception filter.
>> Discussing that with Windows Kernel maintainers, this approach is highly
>> discouraged, considered brittle, and the better solution is Vectored
>> Exception Handling. Vectored Exception Handling is conceptually much more
>> similar to signal / sigaction on Linux and other Unix systems. It will
>> catch all exceptions happening across the process, and no __try / __except
>> will be required. It also removes the requirement to call
>> `RtlAddFunctionTable`.  The exception filter then behaves like a signal
>> handler with the possibility to modify the registers at will, modifying the
>> PC to step over an instruction after an expected Access Violation for
>> example. Vectored Exception Handling is also already used for AOT code.
>> The changes can be found at
>> http://cr.openjdk.java.net/~burban/ludovic_vecexc/. As I am not an
>> author, I have not created a corresponding bug in JBS.
>> Thank you, and looking forward for your feedback!
>> --
>> Ludovic

More information about the hotspot-runtime-dev mailing list