On Sun, 19 Oct 2025 15:37:22 GMT, Jonas Norlinder <[email protected]> wrote:
> Certainly, thanks for asking. Researchers in GC are using the GC start/end > events (https://dl.acm.org/doi/10.1145/3669940.3707217, > https://ieeexplore.ieee.org/document/9804613, > https://dl.acm.org/doi/10.1145/3764118, > https://dl.acm.org/doi/10.1145/3652024.3665510 etc.) to understand various > costs pertaining to GC. I believe one USP of using a JVMTI agent is that it > does not require modification of the benchmarking code and allows usage of > powerful features made available by framework such as libpfm. > > So these JVMTI hooks are used to read CPU performance counters to get some > estimations of various metrics, be it CPU time, cache-misses etc. However > this imposes severe limitations especially when it comes GCs with concurrent > parts. This patch will expand the capabilities for these users using JVMTI > agents to profile applications. I've no doubt that it is useful but it also reasonable to ask if JVMTI is the right API for monitoring GC in 2025. This is a neglected area, the existing events date from 20 years ago, and pre-date concurrent collectors and other advancements. Is this the start of a revival of JVMTI for profiling tools? If we could start again what features would a GC monitor interface have to help troubleshooting, performance monitoring, and research? Would we confident modelling a VM and GC agnostic interface or would there be aspects that are very GC specific? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3426635449
