3

Memory leak in case of many started-dead threads

 1 year ago
source link: https://bugs.openjdk.org/browse/JDK-8297638
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Uploaded image for project: 'JDK'

Memory leak in case of many started-dead threads

Details

  • Type: viewavatar?size=xsmall&avatarId=14703&avatarType=issuetype Bug
  • Status: Open
  • Priority: p4.png P4
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: 21
  • Component/s: core-svc
  • Labels:

Description

The full description is in the bug https://youtrack.jetbrains.com/issue/IDEA-305777/Memory-leak-from-com.jetbrains.jdi.VirtualMachineImpl-when-debugging-programs.
In short: if the program is creating a lot of short living threads and just being run under the debugger with enabled threadStart and threadDeath events enabled, jdi will consume more and more memory until OOM.
The problem is split into two places:
1. VirtualMachineImpl.processBatchedDisposes is invoked only inside waitForTargetReply, so if no commands are sent to the debugger it will never be called and batchedDisposeRequests may grow too big
2. unreachable listeners are removed from VMState.listeners only when something is happening with the debugger (VMState.processVMAction is called), which is not happening in our case, so listeners list grows and grows

We've fixed this in IntelliJ jdi fork this way: https://github.com/JetBrains/intellij-deps-jdi/commit/ca1b639d9fd648dd075f258517fdd1635d0eec2d
https://github.com/JetBrains/intellij-deps-jdi/commit/0b6b28d83e4ceaf3a550ebbf1eaeaf23b650f1c7

probably worth fixing in openjdk as well

Attachments

  1. ThreadsHang.zip2022-11-27 23:06

Activity

[~dholmes] This issue seems to be related to JDK-8296463. The scenario is a bit different (a debugger must be attached) but ultimately the same users will be impacted by both issues.
[~ddamodaran] yes JDK-8296463 would be a factor here - as per the update to the JetBrains bug report. I don't know if mainline OpenJDK has the same JDI issue.
[~eushakov] Can you attach a test case. I noticed the jetbrains issue references an "attached project", but I don't have access to it (it says "There is 1 attachment that is not visible to you").
[~cjplummer] The same testcase (attached zip) which was used for JDK-8296463 should work here. Additional thing is to attach a debugger at the startup.
[~eushakov] Please confirm this.
Ok. I'm just going to launch it with the command line. Any special command line arguments? I assume at the very least I need to enable the debug agent.
yes, just attach the debugger and enable ThreadStartEvent and ThreadDeathEvent, then just leave the program working for some time
It looks like this dates back to JDK 8, maybe longer. In the bug report, the IDE/debugger is running on a JDK 17 build (the target VM is JDK 19 but that doesn't matter for this issue). One approach to try is replacing listeners with a WeakHashMap (with a value of type Boolean, unused) so that additions will automatically expunge stale refs. That should help removeListener implementations too, as they are currently O(n).

People

Assignee:

cjplummer Chris Plummer Reporter:

eushakov Egor Ushakov

Votes: 0 Vote for this issue Watchers: 7 Start watching this issue

Dates

Created: 2022-11-25 05:23 Updated: Yesterday 04:27

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK