ExceptionRegion modeling issues and proposed improvements

[Paul Sandoz]

There is a definite tension here. I really want to lean into the structure of exception handling semantics of the language. But, this is not enforced at bytecode, it’s just a table constructed in the required order to preserve those semantics.

https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-3.html#jvms-3.12

"The nesting of catch clauses is represented only in the exception table. The Java Virtual Machine does not enforce nesting of or any ordering of the exception table entries (§2.10). However, because try-catch constructs are structured, a compiler can always order the entries of the exception handler table such that, for any thrown exception and any program counter value in that method, the first exception handler that matches the thrown exception corresponds to the innermost matching catch clause."

(Thank goodness the jsr and ret instructions were removed!)

It is very tempting to reject lifting the bytecode of a method for which its exception table is structurally ill-formed (we get to decide what that is).


On Oct 10, 2024, at 4:45 AM, Adam Sotona <adam.sotona at oracle.com> wrote:

So good news, after a brief scan I haven't found a single method in the JDK which would violate the LIFO of the exception region entries and exits.

Good! In hindsight perhaps not so surprising given the Java language’s exception handling semantics. I don’t know what kind of exception tables Scala, Closure or Kotlin might generate.



FYI: I've also counted the max exception stack depth and number of gaps.
Here is a frequency table of the max exception stack depths:
0: 205345 // methods with no exception regions
1: 11392
2: 1866
3: 509
4: 205
5: 61
6: 23
7: 16
8: 10
9: 1
10: 3
Across the JDK I found 9792 gaps in the exception regions (split exception regions).
It would be interesting to see a model of the code with 10 layers of try/catch blocks ;)

Ha! I also wonder what Java source looks like?

Paul.


Adam



From: babylon-dev <babylon-dev-retn at openjdk.org<mailto:babylon-dev-retn at openjdk.org>> on behalf of Adam Sotona <adam.sotona at oracle.com<mailto:adam.sotona at oracle.com>>
Date: Thursday, 10 October 2024 at 10:04
To: Paul Sandoz <paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com>>
Cc: babylon-dev at openjdk.org<mailto:babylon-dev at openjdk.org> <babylon-dev at openjdk.org<mailto:babylon-dev at openjdk.org>>
Subject: Re: ExceptionRegion modeling issues and proposed improvements


From: Paul Sandoz <paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com>>
> Is the catch block stack order important? Can we encounter an exception region exit that refers to B when the top of the stack is C?

Intuitively I would say the order should be preserved and my brain model for that is a lifo stack, however that idea is inferred from JLS.
Practically there is nothing preventing to have a bytecode with exception table entries starting and ending independently of each other.
Absolute order of the exception table entries is critical, however the whole exception region (a section of bytecode handling specific exception by a specific handler) can consist of multiple exception table entries and can (theoretically) appear in a different relative order to other regions in different situations.
I'll scan some code to collect all real situations versus what is theoretically possible. I think I've seen gaps (instructions exclusions) of a top level try block, while the nested was uninterrupted (however need to find it to confirm).

Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/babylon-dev/attachments/20241010/b85745f0/attachment-0001.htm>