Today, JFR writes data to disk by default, and there are several benefits compared to storing data in memory. For example, it uses less RAM, and if the JVM crashes, the recording data can easily be accessed on the disk. That said, there are times when recording to memory can be beneficial - not because it has lower overhead, but because disk usage itself can be problematic.

The problem with the current in-memory implementation is that stack trace data is not cleared, causing it to build up over the lifetime of the application, which results in a memory leak. One way to fix this would be to implement chunks similar to those used for disk storage but stored in memory buffers. Instead of creating a new RandomAccessFile during chunk rotation, the implementation could call:

    long chunkId = JVM::createMemoryChunk();

And when the max size is exceeded:

    JVM::destroyMemoryChunk(chunkId);

would be called instead of Files.delete(Path).

On top of the chunked memory feature, an in-process recording stream could be implemented. Instead of reading data from a RandomAccessFile, the data could be copied directly from RAM:

    byte[] bytes = JVM::readMemoryChunk(chunkId, position, 4096);

It might also be useful to get the size of a memory chunk:

    long size = JVM::getMemoryChunkSize(chunkId);