Missing entry in SCC due to decomp count mismatch

[Ashutosh Mehra]

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.
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.
The method in question is
jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z

The assembly phase added two entries for this method in the code cache:

[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'
...
[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'

In the production run the "preload" version was successfully loaded:

[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)

The PrintTieredEvents logs indicate this method was also sent for
compilation during replay training:

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]

Ideally this request should have been fulfilled by the second entry in the
code cache. But instead I see this message:

[0.878s][info ][scc,nmethod ] Missing entry for
'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
(comp_level 4, decomp: 0, hash: 0x493f24e2)

This is followed by the C2 compilation of the method.

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.
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?

[0]
https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938

Thanks,
- Ashutosh Mehra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240724/f651d488/attachment.htm>