RFR: 8339799: Reduce work done in j.l.invoke bytecode generators

[Chen Liang]

On Mon, 9 Sep 2024 22:53:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Misc improvements to InnerClassLambdaMetafactory and InvokerBytecodeGenerator:
> - Define `ClassEntry` early, use it when profitable (there are some warts in the API where using `ce.name(), ce.type()` in a few places means we drop the link to the `ClassDesc` which will then be re-spun in later - should be revisited)
> - Use `mh.invokeBasic()` for zero-arg non-capturing lambda constructor calls(!) 
> - Narrow name validation to the name passed in
> - We were calling `classDesc` twice per factoryType argument, refactored to reuse `argDescs`. 
> 
> Interpreter instrumentation sees 1.5% less bytecode executed on netty startup tests, -2.5% on minimal lambda test. Part of the https://bugs.openjdk.org/browse/JDK-8338542 ClassFile API startup work.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 101:

> 99:     private final String lambdaClassName;            // Generated name for the generated class "X$$Lambda$1"
> 100:     private final ConstantPoolBuilder pool = ConstantPoolBuilder.of();
> 101:     private final ClassEntry lambdaClassEntry;       // Class entry for the generated class "X$$Lambda$1"

Does this improvement go away if remove this change to use explicit class entries? I think I can do some constant pool work to improve ClassEntry retrieval from ClassDesc. Something like #20667, but I will try move the hash to ClassEntry to enforce ClassDesc primacy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20925#discussion_r1751051598