RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v6]
Erik Gahlin
egahlin at openjdk.org
Wed Feb 4 12:46:44 UTC 2026
On Tue, 3 Feb 2026 14:42:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> Did you mean this?
> https://github.com/openjdk/jdk/blob/99bc98357dab78bef2cce7a10c98d13d1e5730e3/src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp#L87-L97
Yes, we start with classes first because that typically makes the most sense to users. The problem with starting with threads is that you can get odd chains if one thread holds references to other threads. Generally, stacks are harder to understand compared to an inner class (e.g. a listener) holding a reference to the outer class.
> I can reverse the order in there and thus get the (roughly) reversed order. I already tested that, but refrained from adding it to the patch.
I think we want to process roots in the same order as in BFS.
> What do you think about printing the actual (first, first and second ...) objects that are referenced by the roots? I think that would often help a lot. It helped me a lot in understanding what happened.
I have used 'jfr print --events OldObjectSample' when debugging issues. At one point, I had a JavaFX GUI that allowed me to explore chains, but I think JMC can do that today. I have not studied non-leaks that much.I don't have a strong opinion on what to show in trace mode, as long as it doesn't slow down product builds.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29382#issuecomment-3847232784
More information about the hotspot-jfr-dev
mailing list