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.
Somewhere between the edition from 2-19 and todays edition 2-24, Netbeans has developed a memory leak. I start PMD with no rules selected and run it on jdk1.4.1_01 source. according to windows Task Manager on the 19th netbeans used 164MB on the 24th netbeans uses 314MB on my laptop I only have 256MBRam and NB just crashes with OutOf memory error if I run the 24th build. Build from 19th works just fine. 1.3.1_07, windowsLookAndFeel IDE Dev (Build 200302240100)
Shouldnt this go to P1 for regression and the crash?
dnoyeB: are you using pmd integration module? Please attach your <userdir>/system/ide.log
More info needed. Atr the steps to reproduce just: 1. Start IDE. 2. Do a PMD on big project several time. ?
yez I am using PMD. its my own modified version though the numbers wont show that.
Created attachment 9135 [details] log file
Their is nothing special in the log. PMD works fine on the other versions of netbeans like 3.4.1 release and the dev build from the 19th.
I've just taken heap dumps before and after PMDing, going to inspect them.
OK, there are several problems in interaction of PMD and NetBeans. One of the problems is that the PMD keeps all visited DataObject with some PMD-failure in a map till the next run, just for easy access to the file/line with failure. This can be done the same way as in other compilers -> jump to the file/line only from the info in the OW, no additional info needed. The bigger problem is that PMD, when trying to get the file content goes through EditorCookie to check whether the file is not currently modified in memory. But this check causes the Java module to actually load the file, parse it, and keep it in memory until somebody calls close() on it. The workaround on the PMD side is trivial, but I think this is a problem of Java module or the architecture itself.
Svata accepted it as Java module problem. (All the JavaEditor instances are referenced from JavaDataLoader.parsingListeners)
Hi, I am the author of the pmd module. > One of the problems is that the PMD keeps all visited > DataObject with some PMD-failure in a map till the next > run, just for easy access to the file/line with failure. > This can be done the same way as in other compilers -> > jump to the file/line only from the info > in the OW, no additional info needed. Could you point me to a the source for the compiler, so I could change that? The second problem, should I do something about it?
Fixed in dev trunk, pending merge to 3.5 /cvs/java/src/org/netbeans/modules/java/JavaEditor.java,v <-- JavaEditor.java new revision: 1.140; previous revision: 1.139
Merged into 3.5 as part of #31576 merge: Checking in JavaEditor.java; /cvs/java/src/org/netbeans/modules/java/JavaEditor.java,v <-- JavaEditor.java new revision: 1.138.4.1; previous revision: 1.138
dnoyeB, can you verify it? Thanks
Sure, Ill try on todays build.
Well I don't see the memory leak, but boy is it ever SLOW! Comparing this to 3.4 release, release seems to take about 3-4 minutes on my computer while the current dev build takes about 15-20 to complete a PMD run on the 1.4 source with no rules selected.
> Comparing this to 3.4 release, release seems to take about 3-4 minutes > on my computer while the current dev build takes about 15-20 to > complete a PMD run on the 1.4 source with no rules selected. bad. Reopen for investigation
I should mention that I can not certify that this change is the cause of the slowness. Something between 3.4.1 release and not caused it. Probably something in the last week or two. If I get time, Ill test builds going backwards. maybe this weekend... All I do is run PMD on the 1.4.0_03 source with no rules selected. Honestly it should whip through files and I got a bug filed with PMD for why it does not. In any event, thats how I timed it.
I was complaining about the Java Source Parser over the weekend bogging down my IDE for the first 2-3 minutes after a project is opened. Seems like the slowness is likely related to this slowness. Heck I dont even know how to word my complaint. Seems like maybe we should close this issue, and open a new one about the slowdown that has occured lately. Since the leak is basically fixed, even if its a bad fix or not. (I think the fix is probably unrelated but we will see)
I opened issue 32062 about the performance slowness.
OK, the leak is fixed. To the slowness: Can the problem be that while you were testing it, the Editor JCU thread was running in paralel and slowing this down? I'll investigate the slowness under 32062.
Whatever happened to be running was caused to run by PMDs actions. But PMD is not doing anything new. Note, I ran exactly same test on 3.4.1 release vs. dev build, and their was significant difference in time.
Performance was due to my debugging configuration with -J-Xnoagent -J-Djava.compiler=NONE