ClhsdbThreadContext.java test is triggering codecache related asserts

When running serviceability/sa/ClhsdbThreadContext.java , the following failure was seen:

 sun.jvm.hotspot.utilities.AssertionFailure: Should have found CodeBlob
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:140)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$46.doit(CommandProcessor.java:1699)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2212)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2182)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2053)
at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500)
]
 exitValue = -1

java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'Thread "Common-Cleaner"' missing from stdout/stderr

at ClhsdbThreadContext.main(ClhsdbThreadContext.java:101)
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$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:833)

The root cause is:

r9: 0x00000176ee380000Error: sun.jvm.hotspot.utilities.AssertionFailure: Should have found CodeBlob
sun.jvm.hotspot.utilities.AssertionFailure: Should have found CodeBlob

This caused the clhsdb threadcontext command to abort, so it never got around to dumping the context of the Common-Cleaner thread.

It looks like in PionterFinder.find() SA has hit some edge case with the address, and found that it is in the codecache, but there is no CodeBlob representing that address, so it asserts. I think instead it should just adapt and later PointerLocation should print something like "Not in CodeBlob".

So far this has only happened on Windows-x64 in a run with the following JVM args:

-Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation -XX:+VerifyOops

Most likely -Xcomp is what triggered it. It seems to have happened consistently in 3 separate runs with this option, so it likely 100% reproducible.