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

Jorn Vernee jvernee at openjdk.java.net
Wed Dec 1 14:46:29 UTC 2021


On Tue, 30 Nov 2021 11:04:44 GMT, xpbob <duke at openjdk.java.net> wrote:

>> Unsafe is used in many Java frameworks.
>> When the framework has a unsafe memory leak , there is no way to know what code is causing it.
>> Add unsafe allocation event to jfr.
>> Records the size and stack allocated.
>> This event is off by default
>
> xpbob has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8277930
>  - remove whitespace
>  - add free and Reallocate event
>  - Merge branch 'openjdk:master' into JDK-8277930
>  - 8277930: Add unsafe allocation event to jfr

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?

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

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


More information about the hotspot-jfr-dev mailing list