RFR: 8367002: Missing compiled exception handler for "recursive" exception

[David Holmes]

On Wed, 8 Oct 2025 02:09:47 GMT, Dean Long <dlong at openjdk.org> wrote:

> In some rare cases, such as a catch type that is loadable but inaccessible, a compiled exception handler may be missing, causing exception handling to incorrectly skip that handler.  Instead, with this fix, we will deoptimize and let the interpreter handle it.  This aligns compiled execution with interpreted.  The new test checks this with a somewhat odd construction: an exception handler that is considered not because it is a match, but because the type in the catch is inaccessible.  In this case the interpreter rethrows IllegalAccessError, not from the bci of the instruction that caused the original exception, but from the bci of the non-matching exception handler.  Whether or not this is the correct behavior for the interpreter is a separate issue.  For now the compiler will continue to follow the precedent set by the interpreter.

test/hotspot/jtreg/compiler/exceptions/IllegalAccessInCatch.jasm line 24:

> 22:  */
> 23: 
> 24: super class IllegalAccessInCatch

Psuedo-code as a comment would be useful for those not fluent in asm.

test/hotspot/jtreg/compiler/exceptions/TestAccessErrorInCatch.java line 30:

> 28:  *
> 29:  * @compile IllegalAccessInCatch.jasm
> 30:  * @run main/othervm -Xbatch TestAccessErrorInCatch

Should this test be disabled if explicit compilation directives (e.g. `-Xcomp`) are being passed in?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27683#discussion_r2412601707
PR Review Comment: https://git.openjdk.org/jdk/pull/27683#discussion_r2412607048