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