<div dir="ltr"><div>Hi Maurizio,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 31, 2023 at 4:44 AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So, my general sense is that having a combinatorial number of exit <br>
points (which will only rarely be taken) might be detrimental to <br>
performance anyway - as C2 will see a lot of "cold" code paths by which <br>
objects can escape. </blockquote><div><br></div><div><div>I agree. If the problem is one how the JVM optimizes code 
with a hot path and a cold path, I don't see how the compiler could ever
 do anything about this problem (either way) in the context of 
try/finally. With try/finally there are always going to be at least two 
code paths regardless of whether the finally block is duplicated or consolidated in the bytecode.</div><div><br></div><div>Note also that the bug you referenced, which talks about a performance degradation, is comparing open-DoSomething-close vs. 
try-with-resources. These are obviously not the same thing - the former has only 
one path and fails to close the resource when an exception is thrown.<br></div></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">That said, even if javac deduplicates the exit <br>
points, I'm not sure that C2 might be able to keep the code in the same <br>
shape as generated by javac, as C2 likes to emit one version of the code <br>
for the "common, hot path", and one version of the code for the <br>
"uncommon, cold path" (which is typically executed when some invariants <br>
are violated). So, reducing bytecode footprint in javac might well <br>
result in more work for the C2 compiler which would have to disentangle <br>
the nest of try/finally blocks. <br></blockquote></div><div><br></div><div>I'm not an expert on C2, but who knows? It also might result in less work, or have no effect. We'd need to do performance testing, or get expert analysis.<br></div><div><br></div><div>I wouldn't be surprised if it has no effect, in which case this issue would simply be about controlling excessive class file size.</div><div><br></div><div>Regardless, that original issue remains - you can't nest more than 10 try/finally blocks without getting an error. That seems pretty absurd.<br></div><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>