ExceptionRegion modeling issues and proposed improvements

[Adam Sotona]

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.

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 ;)

Adam



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


From: Paul Sandoz <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/6aeb7ade/attachment.htm>