<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Archie Cobbs" <archie.cobbs@gmail.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"compiler-dev" <compiler-dev@openjdk.java.net><br><b>Sent: </b>Thursday, July 27, 2023 10:26:14 PM<br><b>Subject: </b>Re: JDK-8308023 - Exponential classfile blowup with nested try/finally<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div>Thanks for your comments.</div><br><div>Bear with me while I play devil's advocate...<br></div><div dir="ltr"><br></div><div dir="ltr">On Thu, Jul 27, 2023 at 3:16 PM Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank">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>What if we compiled <span style="font-family:monospace">try { X } finally { Y }</span> into this:</div><br><div><div><span style="font-family:monospace"> X</span></div><div><span style="font-family:monospace"> Store null in local e1 // new instruction<br></span></div><div><span style="font-family:monospace"> goto L2<br></span></div>L1:<span style="font-family:monospace"> Store exception in local e1<br></span><div><span style="font-family:monospace">L2:</span><span style="font-family:monospace">Y</span></div><div><span style="font-family:monospace"> Load exception from local e1<br></span></div><div><span style="font-family:monospace"> If null, goto L3 </span><span style="font-family:monospace">// new instruction</span></div><div><div><span style="font-family:monospace"> Load exception from local e1</span><span style="font-family:monospace">// new instruction</span></div><span style="font-family:monospace"> Throw exception</span></div><div><span style="font-family:monospace">L3: ...<br></span></div></div></div></blockquote><br><div>It's a well known issue since the introduction of the split-verifier, the alternative is exponential verification time.<br></div></div></div></div></blockquote><br><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 data-marker="__QUOTED_TEXT__">The new one, the split-verifier, is linear but requires StackMapTable attributes and to duplicated finally blocks.</div><div data-marker="__QUOTED_TEXT__"><br data-mce-bogus="1"></div><div data-marker="__QUOTED_TEXT__">see <a href="https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.10.2">https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.10.2</a><br><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;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><br></div><div> </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><div>If you try to generate the code above most JITs will refuse to optimize the code, sharing the nominal path and the exception path is a big no no.<br></div></div></div></div></blockquote><br><div>And this is whose fault... ?</div><br><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 data-mce-bogus="1"></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 data-mce-bogus="1"></div><div>And do not forget that there are several existing Java VMs, so each VM will have to dedicate engineering time to do that optimization.</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;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><br></div><div> </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><div>The official workaround if there are a lot on enclosed try/finally blocks is to use several methods.<br></div></div></div></div></blockquote><br><div>Workaround for whom?</div><br><div>If for the programmer, then so what? The existence of a workaround doesn't mean a bug shouldn't still be fixed.</div><br><div>If for the compiler, then when is the "official" workaround going to be actually implemented?</div></div></div></blockquote><div><br></div><div>For the developer.</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;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"><br><div>Thanks,<br></div><div>-Archie</div></div></div></blockquote><div><br></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;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><br></div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs</div></div><br></blockquote></div></div></body></html>