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

[Claes Redestad]

On Mon, 9 Sep 2024 23:27:14 GMT, Chen Liang <liach 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.

When experimenting with this all the changes in this PR individually moved the needle in the right direction. If you have doubts about this facet in particular I can split it out and we can re-evaluate it together with #20667.

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

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