On Sun, 19 Oct 2025 10:21:54 GMT, Alan Bateman <[email protected]> wrote:
> Would it be possible to expand a bit on this, specifically how it might be > used, and whether it might be used with other JVMTI functions (there aren't > functions to get the process CPU time for example). 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. > there aren't functions to get the process CPU time for example I think there is no need for JVMTI to export such functionality as it should be trivial for a C/C++ application to get process CPU time through other means. However getting GC CPU time (outside the scope of stop-the-world) would be less trivial without this patch. > JVMTI is suited to debuggers and other tooling but it's less clear that it is > relevant for profiling now. I believe JVMTI is still relevant for profiling as it is being used in the GC research community. On a general note, I think exposing GC CPU time at various APIs will serve a different scope of users. At this level we support users that uses advanced profiling techniques with external libraries. Hope this helps. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3419754679
