On Tue, 30 Sep 2025 11:23:13 GMT, Jonas Norlinder <[email protected]> wrote:
> 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? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3356108097
