RFR: 8338532: Speed up the ClassFile API MethodTypeDesc#ofDescriptor

[Chen Liang]

On Sun, 18 Aug 2024 23:48:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> All calls to ofDescriptor during the startup process come from here, which cannot be avoided in a simple way.
>> 
>> 
>> 	at java.base/jdk.internal.constant.MethodTypeDescImpl.ofDescriptor(MethodTypeDescImpl.java:142)
>> 	at java.base/java.lang.constant.MethodTypeDesc.ofDescriptor(MethodTypeDesc.java:60)
>> 	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.methodTypeSymbol(DirectMethodBuilder.java:88)
>> 	at java.base/jdk.internal.classfile.impl.TerminalCodeBuilder.setupTopLocal(TerminalCodeBuilder.java:36)
>> 	at java.base/jdk.internal.classfile.impl.DirectCodeBuilder.<init>(DirectCodeBuilder.java:133)
>> 	at java.base/jdk.internal.classfile.impl.DirectCodeBuilder.build(DirectCodeBuilder.java:106)
>> 	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.withCode(DirectMethodBuilder.java:123)
>> 	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.withCode(DirectMethodBuilder.java:130)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$5.accept(InvokerBytecodeGenerator.java:589)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$5.accept(InvokerBytecodeGenerator.java:567)
>> 	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.run(DirectMethodBuilder.java:144)
>> 	at java.base/jdk.internal.classfile.impl.DirectClassBuilder.withMethod(DirectClassBuilder.java:106)
>> 	at java.base/java.lang.classfile.ClassBuilder.withMethod(ClassBuilder.java:260)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.methodSetup(InvokerBytecodeGenerator.java:292)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.addMethod(InvokerBytecodeGenerator.java:567)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$4.accept(InvokerBytecodeGenerator.java:558)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$4.accept(InvokerBytecodeGenerator.java:555)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$2.accept(InvokerBytecodeGenerator.java:282)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$2.accept(InvokerBytecodeGenerator.java:276)
>> 	at java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:113)
>> 	at java.base/java.lang.classfile.ClassFile.build(ClassFile.java:332)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.classFileSetup(InvokerBytecodeGenerator.java:276)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes(InvokerBytecodeGenerator.java:555)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Invoke...
>
> Hmm, based on your stacktrace I think you are running the exploded image in `build/<arch>/jdk` instead of from a final image, e.g. the one that `make jdk-image` produces in `build/<arch>/images/jdk` - the former will do a lot more stuff during startup, while the latter applies numerous link-time optimizations to reduce lambda and method handle spinning on startup. While speeding up the exploded image is a nice bonus, the runtime images should be the focus of startup optimization work.

This trace shows this is exactly the place fixed by https://github.com/liachmodded/jdk/commit/64fd147bddd085fa3caa437a2b25a3dda3bb517a. `withMethod(String, String, int, MethodTypeDesc)` is not caching the MTD, therefore a re-parse happens, which is quite costly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721131585