ExceptionRegion modeling issues and proposed improvements

[Maurizio Cimadamore]

Ah - got it.

The fundamental issue, which is not visible in the source code, is that 
in some cases a single try/catch can be split into two (or more) 
exception table entries.

Since we need a different exception range for each entry in the table, 
we can, in principle, end up with a combinatorial explosion of 
entry/exit, depending on how many nested try/catch there are, and on the 
paths taken by the code inside said try/catch.

Your proposed solution works because, as you now treat an exception 
range more "as data", you can declare it once and for all (e.g. one 
range per exception table entry) and then, in each block, make sure you 
enter/exit the relevant blocks. So, if you have 3 possible ranges, you 
can enter range 1 and 3 - whereas in the old model you would have needed 
to create a dedicated sequence of blocks where the first block entered 
range 1 and pointed to the second block which entered 3 (and then 
reverse when exiting).

Maurizio

On 09/10/2024 15:59, Adam Sotona wrote:
>
> I would rather describe actual situation on examples:
>
> 1. The simplest example seamlessly matching current model:
>
> try { // enter the top region
>
>     try { // enter the nested region
>
>     }  // leave the nested region
>
>     catch { // handler implicitly a part of the top region
>
>         // here is the nested handler code
>
>     }
>
> } // leave the top region
>
> catch { // handler outside of any regions
>
> // here is the top handler code
>
> }
>
> 2. Example with split (the same as above, just with added gap in the 
> middle)
>
> try { // enter the top region part 1
>
>     try { // enter the nested region part 1
>
>     } catch { // handler implicitly a part of the top region part 1
>
>  // we need to leave the top region part 1
>
> // and we cannot jump to the handler in the other top region part
>
> // so we jump to a synthetic isolated nested region exception handler
>
>    }
>
> } // split - leave the top region part 1
>
> catch { // handler outside of any regions
>
>     // jump to common top region handler
>
> }
>
> ... gap in the regions (may be a single instruction excluded from the 
> exception regions)
>
> try { // enter the top region part 2
>
>     try { // enter the nested region part 2
>
>     }  // leave the nested region part 2
>
>     catch { // handler implicitly a part of the top region part 2
>
>             // we need to leave the top region part 2
>
>             // and jump to a synthetic isolated nested region 
> exception handler
>
>     }
>
> } // leave the top region part 2
>
> catch { // handler outside of any regions
>
>     // jump to common top region handler
>
> }
>
> // synthetic nested region handler
>
> try { // enter the top region part 3
>
>     // here is the nested handler code
>
>  } // leave the top region part 3
>
> catch { // common top region handler outside of any regions
>
> // here is the common top handler code
>
> }
>
> 3. And now add third level, jumps between the region fragments and 
> jumps out of the regions (for example break or continue)... ;)
>
> *From: *Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
> *Date: *Wednesday, 9 October 2024 at 15:55
> *To: *Adam Sotona <adam.sotona at oracle.com>, babylon-dev at openjdk.org 
> <babylon-dev at openjdk.org>
> *Subject: *Re: ExceptionRegion modeling issues and proposed improvements
>
> On 09/10/2024 14:16, Adam Sotona wrote:
>
>     If we wanted to exit the region from block 27, then we'd also need
>     to split, as we might need to exit either %1 or %5 from there, no?
>
>     block 27 is the exception handler of the outer try region(s), so
>     no need to exit it (them)
>
> Maybe this is the bit I'm missing: don't we need to exit exception 
> regions explicitly, even inside catch handlers?
>
> Maurizio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/babylon-dev/attachments/20241009/dbd30af6/attachment.htm>