RFR: 8365972: JFR: ThreadDump and ClassLoaderStatistics events may cause back to back rotations

[Markus Grönlund]

On Wed, 5 Nov 2025 16:35:57 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that changes how`jdk.ThreadDump` and `jdk.ClassLoaderStatistics` events are emitted?
> 
> This change is a short-term solution for users who currently suffer from excessive event data, both in terms of count and size, being emitted at the beginning of a chunk. This high volume of events uses up so much chunk space that it immediately triggers a rotation. That rotation can quickly lead to another, causing back-to-back rotations. As a result, the default maximum size of 250 MB may only cover less than 30 seconds of data. This can happen with the thread dump event if there are many threads (1000) with a large number frames (250). It can also occur with applications that have hundreds of thousands of class loaders.
> 
> The fix is to emit those two events when a new recording starts and then only at the end of every chunk. That way, each chunk contains the event at least once, and users can always see the delta from the beginning to the end of a recording. Emitting events at the end of chunk doesn't cause back-to-back rotations, since they are emitted after the max chunk threshold has been triggered.
> 
> (The long-term plan is to change all events with the period `everyChunk` in default.jfc to work this way, but it is too intrusive to backport, and we need more time to figure out how it should work. One idea is to redefine  `<period>everyChunk</period>`to work in this new way. Another idea is to introduce a new representation called `rotation` for this new behavior, and keep `everyChunk` as is. A third idea is to introduce `beginRecording` and allow multiple values in a setting so you would have `<period>beginRecording,endChunk</period>`)

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28153#pullrequestreview-3432635321