Recordings where stackTrace has been enabled for OldObjectSample events creates an unexpected amount of data.

For example, a recording where OldObjectSample is disabled is 2 MB while one where enabled and stackTrace=true becomes 10 MB. Most likely excessive (or redundant) information is written down. 'jfr summary' reveals that the space is taken by the checkpoint event

The parser log shows a pattern where a large checkpoint happens multiple times. See attached log.txt

[0.699s][trace][jfr,system,parser] New constant pool: startPosition=12945672, size=370710, deltaToNext=-11695, flush=false, poolCount=6
[0.699s][trace][jfr,system,parser] Constant: java.lang.Class[1613]
[0.700s][trace][jfr,system,parser] Constant: jdk.types.Package[281]
[0.700s][trace][jfr,system,parser] Constant: jdk.types.Module[7]
[0.700s][trace][jfr,system,parser] Constant: jdk.types.ClassLoader[13]
[0.700s][trace][jfr,system,parser] Constant: jdk.types.Method[3775]
[0.701s][trace][jfr,system,parser] Constant: jdk.types.Symbol[5470]
...

Each large checkpoint is about 400 kB.

The log can be reproduced like this:

$ jfr -J-Xlog:jfr+system+parser=trace --events Dummy recording.jfr

There could possibly be a similar problem where reference chains are recorded (cutoff > 0)