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

[Archie Cobbs]

On Thu, Jul 27, 2023 at 5:22 PM <forax at univ-mlv.fr> wrote:

> 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.
>
>
> There are two verifiers, the old one that does not use StackMapTable
> attributes has an exponential verification time if JSR/RET are used.
> The new one, the split-verifier, is linear but requires StackMapTable
> attributes and to duplicated finally blocks.
>

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


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

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.

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

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.

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!

-Archie

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