RFR: 8373096: JFR leak profiler: path-to-gc-roots search should be non-recursive [v4]

[Thomas Stuefe]

On Tue, 9 Dec 2025 12:08:16 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> A customer reported a crash when producing a JFR recording with `path-to-gc-roots=true`. It was a native stack overflow that occurred during the recursive path-to-gc-root search performed in the context of PathToGcRootsOperation.
>> 
>> We try to avoid this by limiting the maximum search depth (DFSClosure::max_dfs_depth). That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small.
>> 
>> This RFE changes the algorithm to be non-recursive. 
>> 
>> Note that as a result of this change, the order in which oop maps are walked per oop is reversed : last oops are processed first. That should not matter for the end result, however. The search is still depth-first.
>> 
>> Note that after this patch, we could easily remove the max_depth limitation altogether. I left it in however since this was not the scope of this RFE.
>> 
>> Testing:
>> 
>> - Tested manually with very small (256K) thread stack size for the VMThread - the patched version works where the old version crashes out
>> - Compared JFR recordings from both an unpatched version (with a large enough VMThread stack size) and a patched version; made sure that the content of "Old Object Sample" was identical
>> - Ran locally all jtreg tests in jdk/jfr
>> - GHAs
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   final fixes

I see that we have a problem with very broad objects or large object arrays that are nested with this approach, as the space-time complexity of traversing the net with this approach becomes too large. I'll try to modify the patch to take that into account.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28659#issuecomment-3632232783