On Sun, 18 Aug 2024 23:48:39 GMT, Claes Redestad <redes...@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
