Native API for JFR event producers

[Erik Gahlin]

Hi Nitsan,

Something we didn't discuss during OCW was doing up calls to the Java 
API. I know you mentioned it, but what was the real problem there?

It is cumbersome to code against, but one could imagine a native wrapper 
API with convenience methods. It could be implemented quickly, it is 
easy to maintain and if not part of the JDK, it would work with older 
releases.

Extending JVMTI is more problematic since there are lots of processes 
around it.

Thanks
Erik

On 2020-02-17 07:56, Nitsan Wakart wrote:
> Hi,
> Picking up a conversation from the OpenJDK committers workshop, the
> following feature was requested/suggested:
> "Make the means of producing JFR events available to native agents"
>
> The motivation for this request is to serve use cases where the events
> published come from data sources which are naturally native, e.g.:
> - Memory allocator fragmentation stats (`malloc_stats`)
> - `perf_events`/BPF/dtrace/other profiling
> - Native library counters
>
> This would require something like:
> - Settling on some extension to JVMTI to accommodate the API. Including
> `JfrEvent`.
> - Declaring/reserving event types statically.
> - Recording lifecycle hooks to notify the event sources of
> start/stop/configuration events.
>
> It would make sense for the above to mirror the Java API as much as
> possible for consistency.
> In addition it would be good if the API allowed to describe native threads,
> method calls, and stacks. This is to support the native profiling use cases.
>
> Thanks everyone who participated in the discussion ( Eric, Ron, Alan, Mario
> and others), I hope I capture the sentiment from our conversation
> correctly, please chip in so we can flesh this out :-)
>
> Regards,
> Nitsan