This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Build 200402261900. There is a memory leak when you repeatedly rescan sources looking for tasks. Steps to reproduce: 1) Start a trunk build with a clean userdir 2) Memory meter shows 13,0MB of used heap (I always do several GCs before writing down the number from memory meter) 3) Mount a local FS, e.g. openide/src 4) Wait for code completion DB to be created 5) Memory meter shows 13,9MB of used heap 6) Set the To Do limit in Options to 1000 7) Open To Do window 8) Search for tasks in openide/src FS 9) Memory meter shows 23,2MB of used heap Part of heap listing from a profiler: [ name ] [ # instances] [ size in bytes] String 47363 1136712 char[] 46212 8705864 HashMap$Entry 41826 1003824 <class>[] 29125 2118112 ... CookieSet$R 3403 54448 10) close To Do window 11) open To Do window 12) Memory meter shows 20,3MB of used heap 13) rescan tasks in openide/src FS 14) Memory meter shows 28,7MB of used heap Part of heap listing from a profiler: [ name ] [ # instances] String 47855 char[] 46608 HashMap$Entry 44297 <class>[] 32952 ... CookieSet$R 5687 15) rescan tasks in openide/src FS 16) Memory meter shows 33,8MB of used heap Part of heap listing from a profiler: [ name ] [ # instances] [ size in bytes] String 48122 1154928 char[] 46780 17360168 HashMap$Entry 45815 1099560 <class>[] 35496 2377568 ... CookieSet$R 7207 115312
Provided summary data are useless :-(. Could you please attach allocation traces or even better back references to GC roots. Thank you
Possible culpit is docscan.SourceTasksView.resultsSnapshot cache holding last search results and docscan.Cache class holding negative results. These are necessary to meet responsiveness criteria. Your use case just filled these caches. No memory consuption should grow during further usage.
Sorry, I don't have enough time to resolve this issue. The provided data is just to document the problem and its reproducibility. Please, read the reproduction steps again! The memory usage grows and grows and grows indefinitely with each repeat of the scan. This is definitely not what we/you want! Right?
I'm able to reproduce by refreshing again and again.
I separated into two parts UI and backend. Backend test attached (no memory leak observed).
Created attachment 13713 [details] The backend test
Besides what is it <class>[]?
<class>[] is what JProfiler shows me. I don't know exactly what it means. If you run OptimizeIt on this problem, it may show you some different name for this item on the list of heap usage. BTW, we agreed that this is rather a P2, not P1. Downgrading. Anyway, this *must* be fixed to FCS.
I created a test that detects some leaks in SourceTasksView. /cvs/tasklist/docscan/test/perf/src/org/netbeans/modules/tasklist/docscan/HeapTest.java Notifying you because the test also discovers that initial state is not constant. Is it caused by hidden threading problems? Anyway it complicates exact leak localization (and development of such (stable) tests in general).
Created attachment 13760 [details] A patch that minimizes the leak 20times
Ondra could you review please?
Please, reporter, could you verify fixed issues. Thanks a lot.
Reviewed the fix - it looks fine.
I think I discovered root cause, issue #40676.
Created attachment 13770 [details] Revised patch (no GC dependency)
We cannot deliver clean solution of issue #40676 in 3.6 timeframe. However there exists another substitute working for this case. It has advantage over previous patch that it does not depend on GC (therefore being more deterministics). Could you review, please?
reviewed, looks good too.
Remaining leak estimate: 320b per refresh + 20b per refresh per TODO. For 1000 TODOs it could mean 20320b leak per refresh. Just estimate, actual numbers vary (depends on unknown conditions).
Fix causes threading problems: ava.lang.IndexOutOfBoundsException: Index: 3, Size: 3 at java.util.ArrayList.RangeCheck(ArrayList.java:507) at java.util.ArrayList.get(ArrayList.java:324) at org.netbeans.modules.tasklist.core.TaskList.fireStructureChanged(TaskList.java:279) at org.netbeans.modules.tasklist.core.Task.fireStructureChanged(Task.java:180) at org.netbeans.modules.tasklist.core.Task.clear(Task.java:99) at org.netbeans.modules.tasklist.core.TaskList.clear(TaskList.java:324) at org.netbeans.modules.tasklist.docscan.SourceTasksView.handleRefresh(SourceTasksView.java:1075)
It's not threading, TaskChildren$Monitor fires destroyed event that in turn unregister all TaskNode$Monitor listeners (from same thread so it pass all barriers) and iteration fails.
Created attachment 13791 [details] Addon patch eliminating exception caused by previous one.
40565-leak2.patch & leak-l2.patch gives optimal results. I noticed that remaining leak can be eliminated by user action. Click on current file and back to selected folder. Memory meter goes down. This operation nulls background field that keeps reference to scanned dataobjects. There is no event allowing to do it programatically.
Petr, when are you going to integrate the fixes to trunk and to release36 branch? I will verify it when its there...
Verified in trunk. The huge memory leak is gone. You can integrate to release36. THX.
Reviewers notified.
reviewed also the last patch.
backported to release36.
Verified in release36 branch, build 200403071830.