<div dir="ltr"><div dir="ltr">On Tue, Dec 12, 2023 at 4:41 PM Remi Forax <<a href="mailto:forax@univ-mlv.fr">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)">Your proposal is fighting against the physics of the VM, when you enter in an exception handler (a catch block), the whole stack disapear so you need some compiler magic to store everything which is on stack into locals before calling a switch expression so you can restore it inside the exception handler. I've implemented a very similar kind of transformation 10 years ago, it severly bloats the produced bytecode. Or maybe you are suggesting that this new switch will use a new bytecode construct (inline exception handler ?), it's more or less what JSR/RET was, but perhaps there is a better way. <br></div></div></blockquote></div><div><br></div><div>What follows is a somewhat tangential point so don't let this hijack the core discussion....</div><div><br></div><div>In theory the compiler could "synthesize" subroutines, but this runs into verifier problems. See <a href="https://mail.openjdk.org/pipermail/compiler-dev/2023-July/023848.html">this thread</a> which relates to JDK-8308023.</div><div><br></div><div>So my tangential point is that perhaps this work, along with JDK-8308023, might motivate some thinking about how the verifier could be "smartened up" enough to allow the compiler to safely synthesize true subroutines.</div><div><br></div><div>(Personally, something about JDK-8308023 is really offensive .. a 30 line program produces a 10MB class file.)<br></div><div><span class="gmail_signature_prefix"><br></span></div><div><span class="gmail_signature_prefix">-Archie</span></div><div><span class="gmail_signature_prefix"><br></span></div><div><span class="gmail_signature_prefix">-- </span></div><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>