ConstantDynamic in unvisited catch causes 74X slowdown

[Eirik Bjørsnøs]

On Tue, Jan 25, 2022 at 9:58 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:

Paul, thanks for looking into this!


> I think the compiler is bailing with a complex try body.


Hmm.. The only change I make is switching a ConstantDynamic for an
InvokeDynamic in the catch block. The complexity of the try body doesn't
change at all?


> When there is a finally block the compiler will need to analyze all the
> non-exceptional return points and duplicate the finally block code.
>

"compiler" being javac in this context? Again, I don't really want finally
semantics. It's byte code instrumentation wrapping the method body in try
{body} catch(Throwable t) {LDC;throw t) where LDC is a ConstantDynamic
which is not referenced in the body.


> I need to look in more detail how you are defining the try/catch/block…
> since as you say the LDC occurs on exception cases, but you use a null
> value for the exception (also need to remind myself of the bytecode).


Changing the TRYCATCHBLOCK to use Throwable instead of null for the type
parameter seems to make no difference.

Try this:
>

Extracting the loop into a separate method makes no difference for the
bailout.

The specific Java code here is just an example from a benchmark which
exposed this ConstantDynamic issue. The intended use of the instrumentation
logic is to instrument potentially ALL methods in an application via an
agent, so whichever way I do the instrumentation here, it needs to work for
all kinds of clunky Java code (most of which I do not produce or control
myself :).

For now, I'm working around the issue simply by using invokeDynamic instead
of ConstantDynamic. Most methods don't throw often, so this code path
doesn't need to be heavily optimized.

I could also work around it by also referencing the ConstantDynamic in the
body, but I want the body to be optimally fast so that's not so appealing.

Cheers,
Eirik.