"Memory leak" caused by WorkQueue#topLevelExec

[Viktor Klang]

Hi,

Have you validated that your proposed fix solves the problem? The reason 
I ask is because FJP is extremely performance sensitive where 
instruction placement can have massive performance implications. It 
might be that manually inlining topLevelExec into its caller is 
performance neutral, but I want to make sure that we're looking at a 
problem which is practically solvable by making changes in FJP itself.

The reason I ask is because CountedCompleters tend to have live 
dependency chains both in a tree-like manner and a dependency-chain like 
manner. In general, given the structure you tend to want to null out 
things you don't want to be kept any longer, to minimize the time that 
they are kept alive. As an example, see: 
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L695-L705

On 2025-12-06 15:30, Olivier Peyrusse wrote:
> Could the code be changed to avoid this issue? I am willing to do the 
> work, as well as come up with a test case reproducing the issue if it 
> is deemed needed.

-- 
Cheers,
√


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/concurrency-discuss/attachments/20251206/f2a07b08/attachment-0001.htm>