On Thu, 9 Oct 2025 13:59:05 GMT, Kevin Walls <[email protected]> wrote:
> Questions that this change brings up to me: > > Is there a general understanding or a statement of what it means to be > standard or JDK-specific in this area? If previous JSRs which specified JMX > independently were the spec, and are these days part of the JDK Platform, > what does it mean to be standard or JDK-specific? It's similar to standard APIs vs. JDK-specific APIs. A management interface with HotSpot VM or JDK-specific attributes or operations would be a candidate for the jdk.management module rather than the java.management module. I wasn't directly involved in JSR-174 but there were three VM vendors in the EG at the time. The management interfaces that were defined had to be feasible to implement on all. There was interest in further management interfaces and the Sun JDK defined its extensions in com.sun.management. The word "extension" is significant here because asking the platform MBeanServer for a standard MXBean (either directly or via the standard object name) provides access to additional attributes/operations defined by the extension. It might seem a bit strange to see csm.ThreadMXBean extends jlm.ThreadMXBean, but that was the pattern established back in JDK 5. A lookup of say "java.lang:type=Threading" gives access to csm.ThreadMXBean with the additional attributes and operations defined in the subclass. It may be that some of the attributes or operations in these extensions could be proposed for the standard management interfaces, not clear if this is worth doing. TBH, I think the bigger issue is th at these management interfaces haven't evolved significantly, they pre-date fully concurrent GCs and other significant improvements. Note that are some management interfaces that are clearly HotSpot VM or JDK-specific, e.g. csm.HotSpotDiagnosticMXBean and jdk.management.VirtualThreadSchedulerMXBean. As regards the proposal here. I think the API docs will need work. The standard APIs don't know about non-Java threads. This is why it can't speak of "driver threads" and the "VM thread". It seems reasonable to introduce the notion that garbage collection consuming CPU cycle but anything about STW vs. concurrent GCs is more for an implNote. One of the goals, as I understand it, is to use it in conjunction with JDK-specific OperatingSystemMXBean "processCpuTime" attribute. It's possible to cross link in API docs but its relation to that attribute can't be normative if in a standard API. So I think focus on the specifying the attribute first. So far I think Jonas has demonstrated that it is feasible to implementation as either a standard or extension. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3396681608
