ExceptionRegion modeling issues and proposed improvements

[Paul Sandoz]

On Oct 10, 2024, at 11:36 PM, Adam Sotona <adam.sotona at oracle.com> wrote:



From: Paul Sandoz <paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com>>

> All I was suggesting is to replace the operand whose operation refers to the catch block as a successor with that successor. (Of course it's not really a successor in the conventional sense for either region enter or exit). Just less moving parts.

Yes, let's start with this and see the effect on exits from the nested regions. It will definitely reduce the complexity.


Ok. I suspect with that approach we can support what we have today and the relaxed form you are proposing e.g. an region exit can either refer to an associated region enter by value or explicitly to the handlers by successor.


> The exit and re-enter to handle variable modifications is interesting. Although, those variable modifications should covered by the exception region and if we modify the program otherwise are we not changing its behavior?

The trick is that exception region is interrupted (with zero gap) right after the VarStore. Everything is still covered, just one more flow graph path (passing through the modified var) leads to the handler. Ultimatelly the try blocks should be modeled as each individual op is in its own block with alternative successor leading to the exception handler (that is how verification tests the stack maps). Practically only instructions modifying variables are important and even more practically only instructions modifying variables consumed in the exception handler matter.

Very sneaky :-)

How would this work with control flow? I think you would need distinct handlers corresponding to each store.

FWIW C2 does not bother with anything fancy, it just treats it as a box that cannot be SSA’ed. This may indicate it may not be worth the complexity.

Paul.


Ultimate flow graph of a try/catch:
-(try start)- INS -- INS -- STORE 1 -- INS -- STORE 2 -- INS -(try end)- ...
         \     \      \         \     \         \     \
            ------------------------------------------(handler)- LOAD 1 -- ...

Flow graph reflecting all variable modifications:
-(try start)- INS -- INS -- STORE 1 -- INS -- STORE 2 -- INS -(try end)- ...
         \                      \               \
            ------------------------------------------(handler)- LOAD 1 -- ...


Flow graph reflecting modifications of variables consumed in the handler:
-(try start)- INS -- INS -- STORE 1 -- INS -- STORE 2 -- INS -(try end)- ...
         \                      \
            ------------------------------------------(handler)- LOAD 1 -- ...

Flow graph we have now:
-(try start)- INS -- INS -- STORE 1 -- INS -- STORE 2 -- INS -(try end)- ...
         \
            ------------------------------------------(handler)- LOAD 1 -- ...


And this is the trick that might help:
-(try start)- INS -- INS -- STORE 1 -(try end/re-start)- INS -- STORE 2 -- INS -(try end)- ...
         \                               \
            ------------------------------------------(handler)- LOAD 1 -- ...

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