Here is the technical history related to this issue: as suspected, the problem is introduced with JFR Event Streaming (JDK 14), because there the serialization of thread groups is moved outside of a safepoint. As part of that change, we stopped deleting the instance holding all registered thread groups, which previously, in a preemptive way, cleared out all registered thread groups for an epoch. It cleared out all registered TG entries, including the live ones, to be recreated during the next chunk/epoch. I suspect the thinking was to increase the overall performance by not having threads rebuild the TG entries anew for every chunk. However, a side effect of this, and the bug, is that no TG entries are now removed, not even stale (unloaded) ones. This is therefore also a memory leak. We also introduced a means for the threads themselves to register their metadata, first on thread start, but later also on thread end. Since no normalization scheme was put in place, it means those threads keep writing duplicated information (albeit valid) to the .jfr binary. But the JFR Recorder Thread, writing the initial checkpoint for a chunk, which includes static constants and threads (including thread groups), writes ALL registered and accumulated TG entries (even dead ones). 

For applications with a high churn rate of threads starting and stopping, this can lead to a high number of duplicated jdk.types.ThreadGroup entries, taking up unnecessary space in the .jfr binary file. At an extreme, the constant pool section of the .jfr binary can begin to dominate the entire file, leading to back-to-back file rotations including intensive disk I/O.

A scavenging scheme for clearing dead TG entries and an "is_serialized" scheme should be implemented. Such an "is_serialized" scheme could easily be extended to also cover JavaThreads ("is_serialized(JavaThread) -> is_serialized(ThreadGroups)")