RFR: 8348347: Cleanup JavaThread subclass support in SA

[Chris Plummer]

On Wed, 5 Feb 2025 05:00:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Cleanup SA JavaThread support. Details in first comment:
>> 
>> Testing:
>> - Tier1
>> - Tier2 svc
>> - Tier3
>> - Tier5 svc
>> - Local testing of debuggee using graal java compiler threads. Verified that the compiler threads shows up in jstack output if the property is set.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 36:
> 
>> 34: import sun.jvm.hotspot.utilities.Observer;
>> 35: 
>> 36: /** This class is no longer abstract. Platform dependent functionality is now implmented
> 
> Suggestion:
> 
> /** Platform dependent functionality is now implemented
> 
> "no longer" very quickly loses context if you don't know when it was abstract, or why.

Ok. I can probably just remove the comment. I guess I worded it the way I did to help the reviewer understand (as opposed to a comment just disappearing).

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 161:
> 
>> 159:         virtualConstructor.addMapping("JvmtiAgentThread", JavaThread.class);
>> 160:         virtualConstructor.addMapping("NotificationThread", JavaThread.class);
>> 161:         virtualConstructor.addMapping("AttachListenerThread", JavaThread.class);
> 
> It still seems a shame that we have to enumerate all the thread sybtypes.

In order the create a mirror instance, SA needs to map the hotspot type to the SA type that implements the mirror. We have the same issue with CodeBlob subtypes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23456#discussion_r1942292903
PR Review Comment: https://git.openjdk.org/jdk/pull/23456#discussion_r1942294672