On Fri, 24 Jan 2025 10:19:30 GMT, Kevin Walls <kev...@openjdk.org> wrote:
>> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or >> more DeoptimizeObjectsALotThread threads. This is one of many JavaThread >> subclasses that SA needs to know about, but in this case it does not. When >> SA tries to create a mirror of one of these threads, it fails with: >> >> >> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from >> address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, >> MonitorDeflationThread, AttachListenerThread, StringDedupThread, >> NotificationThread, ServiceThread or JvmtiAgentThread) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178) >> >> >> The following can be used to reproduce this failure. Most SA tests will fail: >> >> make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot >> >> I had to move the native DeoptimizeObjectsALotThread declaration to >> compileBroker.hpp to make it visible to vmStructs.cpp. >> >> I tested with the above "make test" command and ran all svc tier1, tier2, >> tier3, and tier5 tests. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line > 168: > >> 166: JvmtiAgentThread, NotificationThread, MonitorDeflationThread, >> 167: StringDedupThread, AttachListenerThread, >> DeoptimizeObjectsALotThread and >> 168: ServiceThread. The latter seven subclasses of the former. Most >> operations > > The latter eight are subclasses of the former? 8-) Or just "JavaThread, or > its subclasses..." Yes, it should be updated to eight, but I think what would be better is "returns objects of type JavaThraed or one of its subclasses..." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23279#discussion_r1929185927
