<div dir="ltr"><div dir="ltr">On Thu, Jul 27, 2023 at 5:22 PM <<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)"><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>