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.

Bug 175512 - "Project UI" RequestProcessor causing OOME
Summary: "Project UI" RequestProcessor causing OOME
Status: RESOLVED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Infrastructure (show other bugs)
Version: 6.x
Hardware: All Linux
: P1 blocker (vote)
Assignee: Jesse Glick
URL: http://profiler.netbeans.org/files/do...
Keywords: PERFORMANCE
Depends on: 170029 175817
Blocks:
  Show dependency tree
 
Reported: 2009-10-27 13:35 UTC by Petr Hejl
Modified: 2009-11-01 10:52 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Hejl 2009-10-27 13:35:48 UTC
In certain cases the slowness detector correctly starts taking snapshots. However it easily consumes all memory causing
OOME (hundreds of megabytes of StackTraceElements). The result is that instead of slow IDE you get unusable IDE you have
to forcibly terminate.

I'll stop by with heapdump.
Comment 1 Tomas Hurka 2009-10-28 08:10:49 UTC
The problem is not caused by slowness detector. The StackTraceElements in the heap dump are hold by 72204 instances of org.openide.util.RequestProcessor$SlowItem. RequestProcessor#25 has queue (LinkedList#80) which has size 71911 and holds almost all  RequestProcessor$SlowItem instances. The name of the RequestProcessor#25 is "Project UI". More info tomorrow.  
Comment 2 Tomas Hurka 2009-10-29 09:27:59 UTC
URL field contains link to the heap dump.
Comment 3 Tomas Hurka 2009-10-29 09:41:46 UTC
RequestProcessor#25 is the one stored in org.netbeans.modules.project.ui.Hacks.RP static field. 
Reassigning to project to find out, why this request processor has ~72000 scheduled tasks.

To phejl: It would be _very_ useful to have steps how to reproduce this OOME.
Comment 4 Milos Kleint 2009-10-30 08:22:20 UTC
the Hacks' class RP processor is used in a few places.
all were introduced by jtulach in fix for issue 170029
Most are only a single task, being rescheduled.
The only exception is the ProjectsRootNode:784 which seems to spawn a new task on a stateChanged event. I guess that's
where "the miners are accumulating".

reassigning to the author of the 170029 fix.
Comment 5 Jaroslav Tulach 2009-10-30 19:45:20 UTC
The problem is not Hacks.RP (just replaces one RP.gD for another), but post(new Runnable()) in the state method. Jesse 
is author of that code (585ba313709f) and decide what to do. Following diff could be appropriate fix, but I leave it 
for Jesse, I did enough mistakes today already:


diff -r 615567f87a64 projectui/src/org/netbeans/modules/project/ui/ProjectsRootNode.java
--- a/projectui/src/org/netbeans/modules/project/ui/ProjectsRootNode.java       Fri Oct 30 11:02:38 2009 +0100
+++ b/projectui/src/org/netbeans/modules/project/ui/ProjectsRootNode.java       Fri Oct 30 19:44:38 2009 +0100
@@ -781,11 +781,7 @@

         // sources change
         public void stateChanged(ChangeEvent e) {
-            Hacks.RP.post(new Runnable () {
-                public void run() {
-                    setProjectFiles();
-                }
-            });
+            fsRefreshTask.schedule(DELAY);
         }

         @Override

Comment 6 Jesse Glick 2009-10-30 21:02:05 UTC
jtulach's patch looks fine: core-main #f5065f872c52

Not sure how you would reproduce this. Issue #175817 indicates that this code is triggered much more often than it
should be, but certainly not tens of thousands of times.
Comment 7 Quality Engineering 2009-11-01 10:52:57 UTC
Integrated into 'main-golden', will be available in build *200910310201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/f5065f872c52
User: Jesse Glick <jglick@netbeans.org>
Log: #175512: reuse same RP task when Sources changes.