On Mon, 9 Sep 2024 22:53:28 GMT, Claes Redestad <redes...@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
