[GR-70360] Fix JFR memory leak in Java event TLBs#12290
Merged
graalvmbot merged 3 commits intooracle:masterfrom Oct 7, 2025
Merged
[GR-70360] Fix JFR memory leak in Java event TLBs#12290graalvmbot merged 3 commits intooracle:masterfrom
graalvmbot merged 3 commits intooracle:masterfrom
Conversation
2 tasks
christianhaeubl
approved these changes
Oct 6, 2025
Collaborator
Author
|
@christianhaeubl should I make a backport PR to the JDK 25 release branch? |
Member
|
No, that should not be necessary - thanks (I already requested backporting internally, so this should land in the next possible release). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR fixes a native memory leak in JFR. The problem was reported originally by @joggeli34
here #12253
The problem is that JFR Java event buffers are not being retired/reinstated correctly. Instead of these buffers being reused between recordings, they are leaked. The reason for the leak is because we prematurely reset the
javaBufferthread local when stopping a recording. This is is bad because we need to reuse this thread local to reinstate the buffer in the next recording when a new JavaEventWriteris created. Instead, a new buffer gets created and the retired one is lost.This results in a leak of the size (pageSize > 8 * 1024 ? pageSize : 8 * 1024) * THREAD_COUNT per new recording.
The leak only happens when a recording is stopped and a new recording is started while the same threads are still running. This is the scenario when Java event buffers would be retired/reinstated.
The leak was discovered by @joggeli34 because they are using Pyroscope which starts/stops new recordings every 10s. This frequent new recording creation exacerbates the leak.
I used NMT to investigate this by adding more fine grained JFR NMT categories. Notice that committed memory in category JFR1 increases overtime.




After the fix, the memory usage does not increase.
This bug fix should be backported to GraalVM for JDK 25.