[performance] Sometimes Eclipse goes into a state where it allocates memory like crazy and only a restart helps

I created a corresponding issue for JDT, but they think it is a lsp4e problem.

I am just linking to the corresponding JDT issue: https://github.com/eclipse-jdt/eclipse.jdt.core/issues/3634. That issue shows screenshots and attaches a stack trace.

The last comment from a JDT contributor says that the stack trace points to CodeMining and the CodeMining stacktrace given points to lsp4e.

"ForkJoinPool.commonPool-worker-35" #633 [76891] daemon prio=6 os_prio=31 cpu=159560.22ms elapsed=443.99s tid=0x000000011736fe00 nid=76891 waiting for monitor entry  [0x00000003420b6000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at org.eclipse.debug.internal.core.LaunchManager.getLaunches(LaunchManager.java:1385)
        - locked <0x000000070424c3e8> (a java.util.ArrayList)
        at org.eclipse.lsp4e.debug.breakpoints.TextSelectionToIVariable.hasDAPTarget(TextSelectionToIVariable.java:112)
        at org.eclipse.lsp4e.debug.breakpoints.TextSelectionToIVariable.getVariableFor(TextSelectionToIVariable.java:53)
        at org.eclipse.lsp4e.debug.breakpoints.TextSelectionToIVariable.getAdapter(TextSelectionToIVariable.java:42)
        at org.eclipse.core.internal.runtime.AdapterManager.lambda$13(AdapterManager.java:310)
        at org.eclipse.core.internal.runtime.AdapterManager$$Lambda/0x000000700133b2c8.apply(Unknown Source)
        at java.util.stream.ReferencePipeline$3$1.accept(java.base@21.0.5/ReferencePipeline.java:197)
        at java.util.stream.ReferencePipeline$2$1.accept(java.base@21.0.5/ReferencePipeline.java:179)
        at java.util.stream.ReferencePipeline$3$1.accept(java.base@21.0.5/ReferencePipeline.java:197)
        at java.util.ArrayList$ArrayListSpliterator.tryAdvance(java.base@21.0.5/ArrayList.java:1685)
        at java.util.stream.ReferencePipeline.forEachWithCancel(java.base@21.0.5/ReferencePipeline.java:129)
        at java.util.stream.AbstractPipeline.copyIntoWithCancel(java.base@21.0.5/AbstractPipeline.java:527)
        at java.util.stream.AbstractPipeline.copyInto(java.base@21.0.5/AbstractPipeline.java:513)
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(java.base@21.0.5/AbstractPipeline.java:499)
        at java.util.stream.FindOps$FindOp.evaluateSequential(java.base@21.0.5/FindOps.java:150)
        at java.util.stream.AbstractPipeline.evaluate(java.base@21.0.5/AbstractPipeline.java:234)
        at java.util.stream.ReferencePipeline.findFirst(java.base@21.0.5/ReferencePipeline.java:647)
        at org.eclipse.core.internal.runtime.AdapterManager.getAdapter(AdapterManager.java:312)
        at org.eclipse.core.internal.runtime.AdapterManager.loadAdapter(AdapterManager.java:336)
        at org.eclipse.core.runtime.Adapters.queryAdapterManager(Adapters.java:150)
        at org.eclipse.core.runtime.Adapters.adapt(Adapters.java:86)
        at org.eclipse.core.runtime.Adapters.adapt(Adapters.java:115)
        at org.eclipse.debug.internal.ui.codemining.DebugValueCodeMiningProvider.lambda$1(DebugValueCodeMiningProvider.java:69)
        at org.eclipse.debug.internal.ui.codemining.DebugValueCodeMiningProvider$$Lambda/0x0000007002550408.get(Unknown Source)
        at java.util.concurrent.CompletableFuture$AsyncSupply.run(java.base@21.0.5/CompletableFuture.java:1768)
        at java.util.concurrent.CompletableFuture$AsyncSupply.exec(java.base@21.0.5/CompletableFuture.java:1760)
        at java.util.concurrent.ForkJoinTask.doExec(java.base@21.0.5/ForkJoinTask.java:387)
        at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base@21.0.5/ForkJoinPool.java:1312)
        at java.util.concurrent.ForkJoinPool.scan(java.base@21.0.5/ForkJoinPool.java:1843)
        at java.util.concurrent.ForkJoinPool.runWorker(java.base@21.0.5/ForkJoinPool.java:1808)
        at java.util.concurrent.ForkJoinWorkerThread.run(java.base@21.0.5/ForkJoinWorkerThread.java:188)

Thank you.

Start with the linked JDT issue and its attached stack trace, then inspect TextSelectionToIVariable.hasDAPTarget and getVariableFor in the lsp4e debug breakpoints code. Trace how DebugValueCodeMiningProvider reaches those methods and compare the behavior with LaunchManager.getLaunches. Done means the excessive allocation or blocking behavior is reproduced, understood, and covered by an appropriate regression test or fix.