RFR: 8348347: Cleanup JavaThread subclass support in SA [v2]

Chris Plummer cjplummer at openjdk.org
Mon Feb 10 18:18:10 UTC 2025


On Mon, 10 Feb 2025 17:49:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> I think we need a HiddenJavaThread class, and "visibility" cannot just be a boolean field in JavaThread, because virtualConstructor.addMapping wants a mapping to a class that will already know whether it's hidden.
> 
As I just learned from Vladimir's CodeBlob work in #23533, we could actually do without the mapping and instead query a field in the instance to determine which wrapper class to use for it. The problem is that "hidden" is not a field, it is a method, although probably could be changed to a field, which might also help to implement [JDK-8348317](https://bugs.openjdk.org/browse/JDK-8348317). However, implementing that approach still basically requires all the changes in this PR, so I think it is still best to get this one in place and maybe file a followup CR for further improvement (although honestly I don't see myself working on it right away).

> In calling it HiddenJavaThread we might be labelling threads "JavaThread" when they don't run Java, but those I looked at are derived from JavaThread in native hotspot so it must be the right name.

Yeah, all these threads are hospot JavaThread instances. The naming inconsistency really begins there. This PR actually cleans it up by getting rid of the SA isJavaThread(), which was different then the hotspot isJavaThread().

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

PR Comment: https://git.openjdk.org/jdk/pull/23456#issuecomment-2648867520


More information about the serviceability-dev mailing list