<div dir="ltr"><div>During the startup of a quarkus app, I see a particular method that gets C2 compiled almost every time in the production run with the premain branch . I don't see this happening with the mainline.</div><div>The reason this method caught my attention is the significant amount of memory its C2 compilation consumes (between 25-40 mb) compared to the other compilations.</div><div>The method in question is <font face="monospace">jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z</font></div><div><br></div><div>The assembly phase added two entries for this method in the code cache:<br></div><div><br></div><div><font face="monospace">[3.391s][info   ][scc,nmethod ] 2631 (L4): Writing nmethod 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z' (comp level: 4, decomp: 1, has clinit barriers) to Startup Code Cache 'quarkus-getting-started.cds.code'<br></font></div><div><font face="monospace">...</font></div><div><font face="monospace">[7.215s][info   ][scc,nmethod ] 4354 (L4): Writing nmethod 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z' (comp level: 4, decomp: 1) to Startup Code Cache 'quarkus-getting-started.cds.code'</font><br></div><div><br></div><div>In the production run the "preload" version was successfully loaded:</div><div><br></div><div><font face="monospace">[0.695s][info ][scc,nmethod ] 727 (L4): Preloading nmethod 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z' (decomp: 0, hash: 0x493f24e2, has clinit barriers)<br></font></div><div><font face="monospace"><br></font></div><div><font face="arial, sans-serif">The </font><font face="monospace">PrintTieredEvents</font><font face="arial, sans-serif"> logs indicate this method was also sent for compilation during replay training:</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="monospace">0.877593: [force-compile level=4 [jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z] @-1 queues=0,0 rate=0.000000 load=0.007812 k=1.00,1.00 total=56,0 mdo=0(0),0(0) max levels=4,0 compilable=c1,c1-osr,c2,c2-osr status=idle mtd: mdo=18830(8306), 0(0), deps=0]</font><font face="arial, sans-serif"><br></font></div><div><font face="monospace"><br></font></div><div><font face="arial, sans-serif">Ideally this request should have been fulfilled by the second entry in the code cache. But instead I see this message:</font></div><div><font face="arial, sans-serif"><br></font></div><div><div><span style="font-family:monospace">[0.878s][info ][scc,</span>nmethod<span style="font-family:monospace"> ] Missing entry for 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z' (comp_level 4, decomp: 0, hash: 0x493f24e2)</span><br></div><div></div></div><div><br></div>This is followed by the C2 compilation of the method.<div><br></div><div>It looks like the failure to find the second entry is due to a mismatch of the decomp count [0]. The decomp count is stored in the MethodData. </div><div>Is it possible that the method data is not yet installed when replay training is done? If so, is that by design or a bug?</div><div><br></div><div>[0] <a href="https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938">https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938</a></div><div><br></div><div>Thanks,<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">- Ashutosh Mehra</div></div></div></div></div>