<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi,</p>
<p><br>
</p>
<p>I believe a few of us were looking at this some time ago. There
is a range of potential solutions, some with a possibly lesser
impact, but safer, some with potentially bigger impact, but
possibly more dangerous.</p>
<p><br>
</p>
<p>Overall, I am personally a bit worried about adding conditional
jumps that were not in the source code - these might affect way
how the code performs (as Remi says). This might be more OK for
deeply nested try-finally, which are probably already problematic,
but possibly not for a simple/lightly nested try-finally. But
having two ways to generate try-finally is somewhat problematic
for javac.<br>
</p>
<p><br>
</p>
<p>There are potentially safer options, like for example,
considering:</p>
<pre class="c-mrkdwn__pre" data-stringify-type="pre"> try {
a = 0;
} finally {
try {
b = 1;
} finally {
c = 2;
}
}</pre>
this gets translated roughly as:
<pre class="c-mrkdwn__pre" data-stringify-type="pre"> try {
a = 0;
} catch (Throwable t0) {
try {
b = 1;
} catch (Throwable t1) {
c = 2;
throw t1;
}
c = 2;
throw t0;
}
try {
b = 1;
} catch (Throwable t1) {
c = 2;
throw t1;
}
c = 2;</pre>
<p></p>
<p><br>
</p>
<p>We probably could only have one copy of (by just re-wiring
Exceptions table entries, and producing only one copy of the
code):</p>
<pre class="c-mrkdwn__pre" data-stringify-type="pre"> } catch (Throwable t1) {
c = 2;
throw t1;
}
</pre>
<p>It may not seem like a saving a lot, but for deeply nested
try-finally (in the simple form from this report), this actually
saves a lot (because for deeper nesting, the shared snippets get
bigger and bigger). I've had some prototype, but it has some
problems (does not generate proper StackMaps, and allocating the
variable for the exception is somewhat tricky).</p>
<p><br>
</p>
<p>Overall, given the usual complexity of doing anything in Gen, I
believe the inclination was to see if we can wait until javac will
use the ClassFile API to generate bytecode, and revisit then. This
would at least help us generate proper StackMaps much more easier.</p>
<p><br>
</p>
<p>Also please note that the situation will get much more difficult
when there are exits from inside of the try block - return, break,
continue, yield, where break and continue instances can (in
general) break/continue to more than one target. Some unifications
are possible then at the cost of unconditional jump, which may be
OK, but would still need a careful evaluation.</p>
<p><br>
</p>
<p>Overall, I suspect that whatever we do, we would need to run
proper experiments to ensure there's no problem with performance
of the new code.<br>
</p>
<p><br>
</p>
<p>Jan<br>
</p>
<p><br>
</p>
<p>
</p>
<p></p>
On 28. 07. 23 0:51, Archie Cobbs wrote:<br>
<blockquote type="cite" cite="mid:CANSoFxs07oVE=b=R6B-381R+YOt452L+P8Q9BSpmg=XceokeuQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">On Thu, Jul 27, 2023 at 5:22 PM <<a href="mailto:forax@univ-mlv.fr" moz-do-not-send="true" class="moz-txt-link-freetext">forax@univ-mlv.fr</a>>
wrote:</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<div>
<blockquote style="border-left:2px solid
rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt">
<div dir="ltr">
<div class="gmail_quote">
<div>Wait - are you saying the split-verifier
has exponential verification time in certain
cases?</div>
<br>
<div>If so, how is that not just a stupid
verifier bug? Not to mention an easy way to
DOS Java's widely heralded code portability.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
There are two verifiers, the old one that does not use
StackMapTable attributes has an exponential
verification time if JSR/RET are used.</div>
<div>The new one, the split-verifier, is linear but
requires StackMapTable attributes and to duplicated
finally blocks.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Got it. So the old verifier is not really relevant to
this discussion, because we're talking here about class
files that don't use JSR/RET (major version >= 50).<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<div><br>
<blockquote style="border-left:2px solid
rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt">
<div dir="ltr">
<div class="gmail_quote">
<div>Isn't it a JIT's job to be aware of any
such effects (if they exist on some particular
hardware) and deal with them??</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>It has nothing to do with a peculiar hardware, a
JIT is an optimizing bytecode to assembly compiler,
like any optimizing compiler, not all bytecode
shapes are equal.</div>
<div><br>
</div>
<div>The crux of this issue is this question, Why do
want a VM engineer to spend time on a bytecode shape
that no sane bytecode generators will ever generate
?<br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
I don't really understand your point. It sounds to me like
you're saying "Doing anything other than what we're already
doing would be crazy" but without providing any specific
justification.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">What I'm suggesting seems much more
sane to me than what we're currently doing. What's sane about
exponential blowup and excessively duplicated bytecode??<br>
</div>
<div class="gmail_quote">
<div><br>
</div>
<div>While I'm sure you're right that there are JITs out there
that have evolved to work better (or worse) based on typical
(or atypical) bytecode patterns, that's not an a priori
reason to throw your hands up and say something could never
work.<br>
</div>
<div><br>
</div>
<div>In fact, I bet it would be faster without any JIT changes
at all. After all, you're going to have N code paths instead
of 2^N!<br>
</div>
<br>
</div>
<div>-Archie<br>
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">Archie L. Cobbs<br>
</div>
</div>
</blockquote>
</body>
</html>