On Tue, 30 Sep 2025 10:41:41 GMT, Alan Bateman <[email protected]> wrote:
>> I don't think this is appropriately placed in MemoryMXBean. I will discuss >> in the CSR request > >> I don't think this is appropriately placed in MemoryMXBean. I will discuss >> in the CSR request > > The CSR is probably a bit premature as this one is going to require seeing if > the existing MXBeans are the best place for this (at least some of the > original modelling assumed STW collectors) or whether a new management > interface is needed. > > It will need think about whether should be a standard or JDK-specific API. > Right now, the draft API spec makes it sounds very HotSpot VM specific. > > If added to an existing interface then it will need to be a default method > and specifies to have default behavior when not implemented. @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). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3351513274
