ExceptionRegion modeling issues and proposed improvements

[Adam Sotona]

From: Paul Sandoz <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.

> 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.

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/7b8fa7b9/attachment-0001.htm>