In applications with many threads (typically more than 1,000) and deep Java stacks (typically more than 300 frames), the `jdk.ThreadDump` event can become large enough to trigger a recording file rotation by itself. This can cause other events to be removed earlier than expected by the retention policy. A similar issue occurs for the `jdk.ClassLoaderStatistics` event in applications that use several hundred thousand class loaders.

To avoid back-to-back rotations in the default configuration (`default.jfc`), the `jdk.ThreadDump` and `jdk.ClassLoaderStatistics` events are now written only when a recording starts and at the end of a file rotation. They are no longer written at the beginning of a new file created by rotation.