RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time

[Jonas Norlinder]

On Wed, 1 Oct 2025 12:36:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman
>> 
>>> The CSR is probably a bit premature ...
>> 
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
>> 
>>> Right now, the draft API spec makes it sounds very HotSpot VM specific.
>> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
>> 
>>> If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented.
>> 
>> Great point. Should have added a default behavior. Will include that in an updated PR (if we reach a consensus that we should add it to an existing interface).
>
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
> 
> I don't think there are rules or a protocol around this. It's mostly just to avoid trying to get agreement on a direction in two places at the same time. 
> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
> 
> "genesis", "VM operations on the VM thread", ... are very implementation specific. The API docs, esp. the standard APIs, have to VM and independent of implementation. In some places you'll have usage of `@implNote` with details on of the implementation in the JDK.
> 
> I think the main question for the proposal is which management interface is appropriate. The j.l.management API was designed a long time ago (JSR-174, Java 5) and the abstractions it defines (memory, memory manager, memory pools) mean there isn't an obvious place for attributes and operations like the attribute proposed here. On the surface it might seem that "the" GarbageCollectorMXBean is the right place but it's not a singleton, instead there are 2, 3, or 4 management interfaces for each GC. I assume this is why the proposal is currently to add an read-only attribute to MemoryMXBean.
> 
> One idea to try is introducing a JDK-specific MemoryMXBean, meaning in com.sun.management with the other JDK-specific management interfaces. This would give you flexibility to introduce the notion of "GC threads" (the APIs don't know about non-Java threads), and reference OperatingSystemMXBean::getProcessCpuTime as this is also a JDK-specific management interfaces. Would you be able to try that out and see what issue come up?

@AlanBateman if we agree on the new approach, I assume that a CSR would no longer be needed?

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3369044318