Bug ID: JDK-8264899 C1: -XX:AbortVMOnException does not work if all methods in the call stack are compiled with C1 and there are no exception handlers

Versions (Unresolved/Resolved/Fixed)

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.

JDK 21	JDK 22
21.0.3Fixed	22 b03Fixed

The method foo() in the attached Test.java throws MyException. 

$ java -XX:AbortVMOnException=MyException Test.java
$ java -XX:AbortVMOnException=MyException -XX:-TieredCompilation Test.java

successfully results in the expected VM assertion failure:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/christian/jdk/open/src/hotspot/share/utilities/exceptions.cpp:544), pid=116514, tid=116515
#  fatal error: Saw MyException, aborting
#
# JRE version: Java(TM) SE Runtime Environment (17.0) (slowdebug build 17-internal+0-LTS-2021-03-25-1609321.christian...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug 17-internal+0-LTS-2021-03-25-1609321.christian..., mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x8f6906]  Exceptions::debug_check_abort(char const*, char const*)+0x8a

However, running it with -Xcomp and C1 only (TieredStopAtLevel) will not abort the VM:

$ java -XX:AbortVMOnException=MyException -Xcomp Test.java
$ java -XX:AbortVMOnException=MyException -Xcomp -XX:TieredStopAtLevel=1,2,3 Test.java

Exception in thread "main" MyException
	at Test.foo(Test.java:7)
	at Test.main(Test.java:3)

Fix request [21u] A useful fix of this feature, clear repro case. Low risk, changes rarely used feature. Clean backport. Test passes and fails without the fix. SAP nightly testing passed.
25-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/95 Date: 2023-12-23 16:42:28 +0000
23-12-2023
Changeset: 826dcb54 Author: Damon Fenacci <dfenacci@openjdk.org> Date: 2023-06-21 12:27:02 +0000 URL: https://git.openjdk.org/jdk/commit/826dcb5424a931953ac1964e7893aec7ec839862
21-06-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/14240 Date: 2023-05-31 07:06:27 +0000
14-06-2023
There seem to be a specific case, in which "AbortVMOnException" is not taken into account, i.e. when an exception is thrown from C1 compiled code, the whole call stack is also C1 compiled and there isn't any handler for the exception thrown. In this case there is no call to "Exceptions::debug_check_abort" (which checks for a match between AbortVMOnException and the exception being thrown) anywhere while handling the exception. In other cases the "Exceptions::debug_check_abort" method is called: in C1's "exception_handler_for_pc_helper" if a handler is present and from "InterpreterRuntime::exception_handler_for_exception" with the interpreter and C2 (which should deoptimise and run the interpreter code if an exception is thrown). We could possibly check for AbortVMOnException earlier on e.g. when the exception is being thrown (for all cases?).
11-05-2023
It appears exception logging also does not work - not surprising as the code is co-located with the abort-check.
09-04-2021
ILW = Diagnostic flag does not work, with -Xcomp and C1, no workaround (but use C2) = MLM = P4
08-04-2021