RFR: 8365611: Throttle any JFR event

Thomas Stuefe stuefe at openjdk.org
Mon Aug 18 10:00:11 UTC 2025


On Mon, 18 Aug 2025 09:45:20 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

> What motivates this change?
> 
> It does not make any sense to "throttle all events." Also, "all events" at this location only constitute JVM events, not Java events.

I'd like to introduce an event to count allocations via Unsafe.allocateMemory ([1]). We get many customers with unexplainably high RSS footprint, and often it turns out that the culprit is an external library allocating memory via Unsafe.allocateMemory. One example would be Netty. 

What folks currently do is to use techniques like valgrind, replacing the C-Heap with jemalloc or using asyncprofiler. It would be very nice if we could do this with JFR itself; it is certainly capable.

But these calls can be relatively fine-grained. Often not, but sometimes they are. If they are, it makes sense to make this new event "throttleable" and throttle it by default to a sensible level.

Apart from all of that, is this not something that is cleaner and just makes sense? You's avoid some ugly and more costly switch case constructs that are executed on every event, don't you?

[1] https://github.com/openjdk/jdk/compare/master...tstuefe:jdk:refs/heads/JFR-Unsafe.allocateMemory

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

PR Comment: https://git.openjdk.org/jdk/pull/26801#issuecomment-3195983563


More information about the hotspot-jfr-dev mailing list