RFR: 8277930: Add unsafe allocation event to jfr [v5]

[Erik Gahlin]

On Wed, 1 Dec 2021 14:43:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I ran some benchmarks as well: http://cr.openjdk.java.net/~jvernee/UnsafeTest.java
> 
> I see about a 6 ns increase in benchmark times with the new coded added in (regardless of allocation size), which sounds about right. An unsafe allocation and free takes about 90 ns on my machine with the latest JDK, so the regression is ~6%. (I'm not sure if that's worth worrying about, see below).
> 
> Whether this is a hot path or not: I think most user applications that use these APIs are doing so indirectly through direct ByteBuffers, and most of those that I've seen use memory pools to avoid doing BB allocations (which can be slow due to the need to wait for reference processing for instance).
> 
> I can't really say if direct calls, or indirect call through other paths than direct ByteBuffers are a hot path in applications, but I'd be surprised if they were, tbh, since generally people seem to think of `malloc` as slow (something I've observed in practice as well), and try to build their own allocators on top if they want more speed.
> 
> Maybe it's an idea to implement these events in Java code instead? (using the JFR mirror events). I think the overhead should always be zero if the events are disabled in that case, right?

Thanks, that were the numbers I was looking for!

We could do them at zero cost in Java (disabled) if we use bytecode instrumentation. If we use mirror events, it may not always work out due to inlining depth. There is also additional startup cost when using Java events.

My worry is that very few people will actually turn these events on, but the rest of the world (99,9999%) will pay the additional 6 ns overhead for every native allocation. We are planning some rewrites for JDK 19 when comes to Java events to reduce the startup cost. It could worth to see if they could be turned into Java events (with zero overhead), similar to the SocketRead/SocketWrite events.

I also wonder if the events should be called NativeAllocation, NativeReallocation and NativeFree, so they are not tied so hard to the Unsafe implementation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6591