This is a replacement CR for JDK-8269982, which had to be made confidential, and also which has changed behavior, so I thought it best to start from scratch.

JDK-8269982 originally described a sun.jvm.hotspot.debugger.UnmappedAddressException when running the following 4 core files tests:

serviceability/sa/ClhsdbPstack.java#id1
serviceability/sa/ClhsdbFindPC.java#id3
serviceability/sa/ClhsdbFindPC.java#id1
serviceability/sa/ClhsdbCDSCore.java

These tests are now called:

serviceability/sa/ClhsdbPstack.java#core
serviceability/sa/ClhsdbFindPC.java#xcomp-core
serviceability/sa/ClhsdbFindPC.java#no-xcomp-core
serviceability/sa/ClhsdbCDSCore.java

Also, the UnmappedAddressException has been replaced by UnknownOopException, but the stack trace is basically the same:

sun.jvm.hotspot.oops.UnknownOopException
at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:193)
at jdk.hotspot.agent/sun.jvm.hotspot.oops.VMOopHandle.resolve(VMOopHandle.java:61)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.getThreadObj(JavaThread.java:353)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.getCurrentParkBlocker(JavaThread.java:405)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:82)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:79)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$30.doit(CommandProcessor.java:1124)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2090)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2060)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1931)
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)

However, due to JDK-8293006, which was pushed about a week ago, the above exception is caught and not considered fatal since it can happen when you are in the middle of a GC. So instead in the log you will see the following warning:

WARNING: could not get Thread object: sun.jvm.hotspot.oops.UnknownOopException: 0x00000007dff299d0

Because of this warning, we cannot get the name of each thread being dumped, so the tests can fail in different ways. ClhsdbPStack fails with:

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

Lastly, even getting as far as the above failure takes some work, because getting core files on macOS Monterey has it's challenges, especially on aarch64. First make sure developer security mode is enabled:

$ sudo DevToolsSecurity -enable

Next make sure /cores is writable:

$ sudo chmod 1777 /cores

Next, until JDK-8293550 is fixed, you need to manually add the com.apple.security.get-task-allow entitlement after the build complete (and do this every time hotspot is rebuild):

$ /usr/libexec/PlistBuddy -c "Add :com.apple.security.get-task-allow bool true" tmp.entitlements

$ codesign -s - -f --entitlements tmp.entitlements build/macosx-aarch64-debug/images/jdk/bin/java