RFR(S): 8247941: Use Vectored Exception Handling on Windows

[David Holmes]

Hi Ludovic,

I can't review the details here as it is not something I know about. The 
AOT folk (Bob V. cc'd) were the last to make changes in this area so it 
would be good if they chimed in on the review thread. :)

With regard to the test a couple of points.

First please fix the copyright lines so there is only the single year 
"2020," (the comma is still needed).

Second rather than using ifdefs in the native code you can exclude it 
from being built other than on Windows. This should work:

diff -r 3b3965c0cce5 make/test/JtregNativeHotspot.gmk
--- a/make/test/JtregNativeHotspot.gmk
+++ b/make/test/JtregNativeHotspot.gmk
@@ -874,6 +874,7 @@
      BUILD_HOTSPOT_JTREG_EXCLUDE += exesigtest.c libterminatedThread.c
      BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libatExit := jvm.lib
  else
+    BUILD_HOTSPOT_JTREG_EXCLUDE += libExternalExceptions.c
      BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libbootclssearch_agent += -lpthread
      BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libsystemclssearch_agent += 
-lpthread
      BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libgetsysprop001 += -lpthread

Thanks,
David
-----

On 5/08/2020 7:03 am, Ludovic Henry wrote:
> (Renaming subject to include bug id, original discussion at [1]).
> 
> Webrev: http://cr.openjdk.java.net/~luhenry/8247941/webrev.00/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8247941
> 
> I've uploaded the webrev at the link above.
> 
> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040228.html
> 
> -----Original Message-----
> From: hotspot-runtime-dev <hotspot-runtime-dev-retn at openjdk.java.net> On Behalf Of Ludovic Henry
> Sent: Tuesday, August 4, 2020 8:34 AM
> To: Thomas Stüfe <thomas.stuefe at gmail.com>; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(S): Use Vectored Exception Handling on Windows
> 
> Hi,
> 
> An update on my current exploration is long overdue.
> 
> # On the use of Unhandled Exception Handling.
> Unfortunately, this is a dead-end because UEH itself relies on Structured Exception Handling to catch any uncaught exception at the top-most frame, and then needs a properly unwindable stack. This is not the case for Java frames as Hotspot follows its own internal ABI, making it impossible for the native unwinder (which doesn't know about the Java ABI) to walk the stack frames. The easy fallback is simply to keep the existing `__try {} __except (topLevelExceptionFilter(...)) {}` and call to `RtlAddFunctionTable` to add such try/except block to the code cache.
> 
> # On the use of Vectored Exception Handling
> Despite UEH not being usable in our case, VEH is still helpful in getting Hotspot to treat Hotspot related exceptions first and to separate the normal exception handling from the crash handling.
> 
> I'll post an updated webrev with these changes later today.
> 
> Thank you,
> Ludovic
>