Native API for JFR event producers

[Marcus Hirt]

Hi all,

Did this get anywhere? It's on my top 10 list of things that would make JFR
even more useful. :)

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Från: hotspot-jfr-dev <hotspot-jfr-dev-bounces at openjdk.java.net> För Erik
Gahlin
Skickat: den 21 februari 2020 01:00
Till: Nitsan Wakart <nwakart at gmail.com>
Kopia: hotspot-jfr-dev <hotspot-jfr-dev at openjdk.java.net>
Ämne: Re: Native API for JFR event producers

Hi Nitsan,

I need to think about this for a while. I will get back to you.

Thanks
Erik

> On 18 Feb 2020, at 16:43, Nitsan Wakart <nwakart at gmail.com> wrote:
> 
> 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
>>