Missing entry in SCC due to decomp count mismatch

[Vladimir Kozlov]

Thank you for report, Ashutosh

Is this with one step workflow? With one step workflow we should ignore decomp count because code is generated not 
during execution but based on training data in forked VM - no deoptimization happens there.

`decomp count` was introduced for 5 steps workflow when we generate aot code as we execute application with idea that 
production run will follow the same compilation/deoptimization steps.

Actually I implemented it before we start using TD to trigger compilation. May be this is the reason that 5 steps 
workflow is slow now when we use TD. I need to check.

Thanks,
Vladimir K

On 7/24/24 7:54 AM, Ashutosh Mehra wrote:
> 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 PrintTieredEventslogs 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 
> <https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938>
> 
> Thanks,
> - Ashutosh Mehra