[Discussion] Making the native JFR ticks getter function semi-public

Jaroslav Bachorík jaroslav.bachorik at datadoghq.com
Tue Mar 9 16:09:46 UTC 2021


Hello,

I would like to propose exporting a symbol for obtaining the current
value of the JFR ticks counter (which is used to record the events'
timestamps).

The rationale behind this proposal is to make external profilers (eg.
async profiler) to better integrate with the built-in JFR recordings.
Nowadays the events generated from the external profilers are using
their own timestamp sources and as a result the recordings may (and
will) experience tearing. With the ability to query the JFR native
ticks count directly one could easily correlate any built-in recording
with any external recording within the resolution of the timestamp
provider.

I am not proposing to introduce a new public API here - rather going
the way of 'AsyncGetCallTrace' when one needs to manually load the
shared JVM library and lookup the symbol. While it takes slightly more
effort for the consumers it allows graceful degradation when the
symbol can not be resolved in older or newer (if that export will be
removed) JVMs.

A simplistic change is drafted at
https://github.com/openjdk/jdk/compare/master...DataDog:jb/export_ticks

With that change in place I am able to obtain the JFR ticks from a JVMTI agent.

Please, let me know what you think about this proposal. If it will be
considered useful I will finalize the change and open a corresponding
PR.


Cheers,

-JB-


More information about the hotspot-jfr-dev mailing list