Native API for JFR event producers

[Nitsan Wakart]

Hi Erik,
I would argue it is a very inconvenient back door to work through. It would
deter implementors and in some cases just not work. In particular:
* I don't think it's a viable option for any signal handling event source
* I think the overheads introduced by upcalls will similarly make it too
slow for high frequency callers

One of the use cases I have in mind is repurposing Async-Profiler (allows
profiling on perf_events, itimer etc) as a JFR event source, I don't
believe going via the Java API would work.
An alternative to JVMTI is whatever limbo AsyncGetCallTrace lives in. It
allows tool builders to integrate and makes no promises that the API is
available beyond OpenJDK.
Thanks,
Nitsan

On Tue, Feb 18, 2020 at 4:50 PM Erik Gahlin <erik.gahlin at oracle.com> wrote:

> 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
>