<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">Is there any case where we
would want to nest BBs but allow the nested BB to bind a label
defined by the parent BB? I don't think so; what we're
basically saying is that if you define a label in a block, it
should be (a) defined before you finish building the block and
(b) can only be defined in that block, not in sub-blocks. Since
LabelTarget is part of the base API, we probably have to
document this constraint on valid labels targets. <br>
<br>
if we have nested trys, each with finally blocks, I think we
have to walk the stack of BBs to get this right:<br>
<br>
Y: <br>
while (goop) {<br>
try { <br>
</font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace"> </font></font> X: <br>
</font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace"> </font></font> while
(blah) { <br>
</font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace"> </font></font> try { <br>
</font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace"> </font></font> if (wah)
continue X;<br>
</font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace"> </font></font> // need A
but not B here<br>
</font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace"> </font></font>
if (wooga) continue Y;<br>
// need A and B here<br>
</font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace"> </font></font> }<br>
</font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace"> </font></font> finally { A }<br>
</font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace"> </font></font> }<br>
</font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace"> </font></font> finally { B }<br>
}<br>
<br>
The first one uses a label defined in the outer try scope, so we
only inline finally A here. The second uses a label defined
outside the outer try scope, so we have to inline A and B (in
the right order) here. <br>
</font></font><br>
<div class="moz-cite-prefix">On 8/30/2022 5:33 PM, Paul Sandoz
wrote:<br>
</div>
<blockquote type="cite" cite="mid:3BC824FC-F922-4D9D-8B3B-EA368E0271B4@oracle.com">
<pre class="moz-quote-pre" wrap="">Here’s an initial try at that.
<a class="moz-txt-link-freetext" href="https://github.com/openjdk/jdk-sandbox/compare/classfile-api-branch...PaulSandoz:jdk-sandbox:try-catch-finally-builder?expand=1">https://github.com/openjdk/jdk-sandbox/compare/classfile-api-branch...PaulSandoz:jdk-sandbox:try-catch-finally-builder?expand=1</a>
BlockCodeBuilder tracks labels created via newLabel, and returns a “live” set of those labels. When a label is to be bound we reject labels that are not members of that set (we need to be careful to propagate the LabelTarget pseudoinstruction to the terminal builder).
We inline a finally block if a the target label of a branch instruction is not a member of the block's labels.
Ideally when block goes out of scope then all the block’s labels become “dead” and therefore they can never be used as targets (or bound if not already).
Paul.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Aug 25, 2022, at 5:49 AM, Brian Goetz <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com"><brian.goetz@oracle.com></a> wrote:
So here's another possible thought: what if BlockBuilder could dispense labels, as well as dispensing blocks, and could then keep track of containment? So if you are branching to a label *outside this block builder* (including returning), we'd inline the finally at that point. (With nested block builders, we'd have to keep track of which BBs belonged to other BBs, but we already do this.)
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<br>
</body>
</html>