On Wed, 1 Oct 2025 12:36:39 GMT, Alan Bateman <[email protected]> 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
