<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#467886" vlink="#96607D" style="word-wrap:break-word;line-break:after-white-space">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Paul,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">see my comments inline.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="color:black">From:
</span></b><span style="color:black">Paul Sandoz <paul.sandoz@oracle.com><br>
<br>
</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">> I am guessing you explicitly generated the bytecode example? although it is indicative of similar issues for bytecode generated from source?<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I've prepared the example as synthetic, however code compiled from source can contain split try blocks and handlers detached from their natural position according to the code flow. Try catch blocks and handlers
are position-based, so every bytecode instruction can easily identify the exception stack, however hardly to reach that state from code flow. In many situations a single bci offset is almost a singularity, where BytecodeLift needs to create a graph of synthetic
blocks representing various flow transitions around that point.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> It’s not clear to me from this example why we need to detach the referencing of catch blocks from the exception region entry op.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Yes, the example was not the best. The main point is that requirement to match exception region exit with its dominant region entry is extremely complex. Single-entry style of the exception region model is
far from the exception table wrapping bytecode offsets orthogonally to the code flow. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> Will it always be the case that an exception.region.enter will dominate a corresponding exception.region.exit? It seems so, and if so an exit can reference an enter. <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Unfortunately, no. </span>Exception.region.exit from the given exception.region will always be dominated by a set of exception.region.entries into the same region, however not always dominated by the single
specific exception.region.enter. Entries to the region represent a set dominant to the exits, however they might not be individually dominant. <span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> Is it related to region exit and re-entry along some particular path of control where eventually all paths join to the region exit? <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The exception regions are in many cases orthogonal to the flow graph, so the condition that re-entries should be dominated by a single entry does not reduce the complexity.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> AFAICT another change in behavior is that a return from a method requires no preceding region exits (similar to throw).<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I didn't notice there is a difference between athrow and return now. Both are terminating the code flow so how the exception stack should behave after return according to the current model?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> Also with your proposal I don’t yet know the implications when lowering try/catch/finally blocks.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">As we discussed - if it is no allowed to jump randomly across bodies, it is probably difficult to model try/catch/finally using the bodies, because the flow may jump across them. If a body can have multiple
enter and exit points (and related continuations inside the body and in the parent body flow), then it can model also split try/catch/finally blocks with breaks and continues. If we have this, lift directly to this model and skip the low level
</span>exception regions<span style="font-size:11.0pt">.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> What about the following? (I am unsure of the cbranch in block_4)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal">As I mentioned above - the single entry dominance condition does not reduce the complexity. Unless we will workaround it by entering and exiting all regions in the entry block, so all following entries will have its single dominant entry.
It is similar to the variables initial value, which needs to be initialized with synthetic default value when there is no single dominant VarStoreOp. My proposal makes ExceptionRegion similar to Var declaration (without an initial value).
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>