ConstantDynamic in unvisited catch causes 74X slowdown

[Paul Sandoz]

Yeah, I blasted off my email too quickly, confusing source compilation with runtime compilation! 

All I did was reduce the cost of method that could not be compiled, so the perf results were similar with and without condy.

Paul.

> On Jan 25, 2022, at 1:35 PM, Eirik Bjørsnøs <eirbjo at gmail.com> wrote:
> 
> 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.