On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplum...@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/Thread.java line 92:
> 90: public boolean isMonitorDeflationThread() { return false; }
> 91: public boolean isAttachListenerThread() { return false; }
> 92: public boolean isDeoptimizeObjectsALotThread() { return false; }
Is this method used anywhere?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23279#discussion_r1927740178
