JDK-8308023 - Exponential classfile blowup with nested try/finally

[Archie Cobbs]

Hi Maurizio,

On Mon, Jul 31, 2023 at 4:44 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> So, my general sense is that having a combinatorial number of exit
> points (which will only rarely be taken) might be detrimental to
> performance anyway - as C2 will see a lot of "cold" code paths by which
> objects can escape.


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.

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.


> That said, even if javac deduplicates the exit
> points, I'm not sure that C2 might be able to keep the code in the same
> shape as generated by javac, as C2 likes to emit one version of the code
> for the "common, hot path", and one version of the code for the
> "uncommon, cold path" (which is typically executed when some invariants
> are violated). So, reducing bytecode footprint in javac might well
> result in more work for the C2 compiler which would have to disentangle
> the nest of try/finally blocks.
>

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.

I wouldn't be surprised if it has no effect, in which case this issue would
simply be about controlling excessive class file size.

Regardless, that original issue remains - you can't nest more than 10
try/finally blocks without getting an error. That seems pretty absurd.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230731/ff91dc64/attachment.htm>