[Native Image] JFR Leak profiler does not write constant data correctly

[roberttoyonaga]

Describe the Issue

What's happening in Hotspot is that the thread and stacktrace constant data are being cached and only written out when the OldObjectSample events get emitted. OldObjectSample events are special because they are only emitted at the end of a recording, not every chunk rotation. However, in SVM we are serializing the thread and stacktrace data normally like we do for any other event. This is bad because the constant data may get written out too early in chunk1 while the recording later finishes in chunk2. Thus separating the constant and event data. We probably didn't catch this before in tests because test recordings are generally only 1 chunk long.

Using the latest version of GraalVM can resolve many issues.

• I tried with the latest version of GraalVM.

GraalVM Version

All versions of GraalVM that contain support for the OldObjectSample event are affected, even master.

Operating System and Version

Fedora linux

Troubleshooting Confirmation

• I tried the suggestions in the troubleshooting guide.

Run Command

N/A

Expected Behavior

When a recording consists of two chunks, the OldObjectSample events in emitted when the recording ends (in the 2nd chunk) should have readable constant data.

Actual Behavior

Thread and stacktrace data cannot be read of samples taken in the first chunk. The second chunk is unaffected.

Steps to Reproduce

1. Start a JFR recording with the OldObjectSample event enabled.
2. Allow sampling in the first chunk.
3. Force a chunk rotation by dumping the recording data to a file.
4. Allow sampling in the second chunk.
5. End the recording and inspect the .jfr file.
6. Notice that samples taken in the 2nd chunk do not have readable constant data.

Additional Context

No response

Run-Time Log Output and Error Messages

No response