A frequent scenario I encounter when analyzing native OOM scenarios at customers is that third-party libraries use Unsafe.allocateMemory to allocate chunks of native memory. Netty is one such example.
Typically we can ascertain with NMT that yes, someone calls Unsafe.allocateMemory. But from then on, we fly blind. We have to guess since we don't have stack traces. Folks then start using tools like hooking in a different libc implementation (e.g. jemalloc) or asyncprofiler to continue analysis. Using tools may not be possible in production scenarios.
It would therefore be nice to have a JFR event for these events to enable this analysis with JFR.
There is one minor issue, though, that since this event is externally triggered, we cannot predict its frequency. Therefore, such an event should be throttleable. We have JDK-8365611 for this which should go in first.
Typically we can ascertain with NMT that yes, someone calls Unsafe.allocateMemory. But from then on, we fly blind. We have to guess since we don't have stack traces. Folks then start using tools like hooking in a different libc implementation (e.g. jemalloc) or asyncprofiler to continue analysis. Using tools may not be possible in production scenarios.
It would therefore be nice to have a JFR event for these events to enable this analysis with JFR.
There is one minor issue, though, that since this event is externally triggered, we cannot predict its frequency. Therefore, such an event should be throttleable. We have JDK-8365611 for this which should go in first.
- is blocked by
-
JDK-8365611 Use lookup table for JfrEventThrottler
-
- Open
-