Seeing the following failure in the Loom repo.

java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr
at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:306)
at ClhsdbFindPC.main(ClhsdbFindPC.java:328)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:577)
at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:142)
at java.base/java.lang.VirtualThread.run(VirtualThread.java:270)
at java.base/java.lang.VirtualThread$VThreadContinuation.lambda$new$0(VirtualThread.java:155)
at java.base/jdk.internal.vm.Continuation.enter0(Continuation.java:349)
at java.base/jdk.internal.vm.Continuation.enter(Continuation.java:342)

Note this is not the same as JDK-8269881, which can potentially produce this same failure message. The difference is that for this CR, the stack dump of the SteadyStateThread is present. For JDK-8269881 it is not. The reason it is failing is because for some reason LingeredApp.steadyState is not compiled anymore, even though we run with -Xcomp

"SteadyStateThread" #14 prio=0 tid=0x0000fffbd43d3a50 nid=1523267 waiting for monitor entry [0x0000fffba9b0e000]
   java.lang.Thread.State: UNKNOWN
   JavaThread state: _thread_blocked
 - jdk.test.lib.apps.LingeredApp.steadyState(java.lang.Object) @bci=8, line=537, pc=0x0000fffbbc593fac, Method*=0x0000fffba0403638 (Interpreted frame)
- waiting to lock <0x00000000c1d0f970> (a java.lang.Object)
 - jdk.test.lib.apps.LingeredApp$1.run() @bci=4, line=543, pc=0x0000fffbbcde5ac8, Method*=0x0000fffba0403eb0 (Compiled frame [deoptimized])

hsdb> + findpc 0x00007fb79c5dda75
Address 0x00007fb79c5dda75: In interpreter codelet: monitorenter [0x00007fb79c5dd9c8, 0x00007fb79c5ddbe0) 536 bytes

This happens with the following variant of the test:
  serviceability/sa/ClhsdbFindPC.java#xcomp-core