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

[Archie Cobbs]

Thanks for your comments.

Bear with me while I play devil's advocate...

On Thu, Jul 27, 2023 at 3:16 PM Remi Forax <forax at univ-mlv.fr> wrote:

> What if we compiled try { X } finally { Y } into this:
>
>     X
>     Store null in local e1         // new instruction
>   goto L2
> L1: Store exception in local e1
> L2:Y
>     Load exception from local e1
>     If null, goto L3               // new instruction
>     Load exception from local e1// new instruction
>   Throw exception
> L3: ...
>
>
> It's a well known issue since the introduction of the split-verifier, the
> alternative is exponential verification time.
>

Wait - are you saying the split-verifier has exponential verification time
in certain cases?

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.


> 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.
>

And this is whose fault... ?

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??


> The official workaround if there are a lot on enclosed try/finally blocks
> is to use several methods.
>

Workaround for whom?

If for the programmer, then so what? The existence of a workaround doesn't
mean a bug shouldn't still be fixed.

If for the compiler, then when is the "official" workaround going to be
actually implemented?

Thanks,
-Archie

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