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.
While researching the leak described in issue 60255 for CMP's, I ran a number of tests against web projects as well, in particular, creating/closing 10 web projects in succession (w/ GC's in at several quantified points), then restarting and opening/closing those 10 web projects in succession. The results suggested that every time a unique web project is opened, then closed, there is (approximately) 300k memory leak. Opening the same project over and over does not impact this, other than the initial 300k. It is possible that this is just garbage collector weirdness. As I was unable to get any real profiling tool to work so far, I do not have any hard data that there is a leak and exactly what it is, but the conditions seem very suspicious. This is on Solaris w/ 64-bit JVM (1.5.0_05 and also 1.6.0 b61). I also viewed similar behavior when the server was Tomcat or Sun App Server. I did not take measurements against any other server.
We profiled it and the reference is hold by Navigator component. After discussion with tzezula I'm closing it as a duplicate of issue #67025. *** This issue has been marked as a duplicate of 67025 ***
I am not sure how did you profile it. I tried something similar today with jmap + jhat and I see couple of suspisious reference chains that hold WebProject even when it is closed. Take a look at #70150, #70157, #70161, #70165, #70172. Yet another chains: Static reference from org.netbeans.api.project.libraries.LibraryManager.instance (from class org.netbeans.api.project.libraries.LibraryManager) : --> org.netbeans.api.project.libraries.LibraryManager@0x870efc98 (28 bytes) (field cache:) --> java.util.ArrayList@0x870f2938 (20 bytes) (field elementData:) --> [Ljava.lang.Object;@0x870f6758 (48 bytes) (Element 1 of [Ljava.lang.Object;@0x870f6758:) --> org.netbeans.api.project.libraries.Library@0x870f27b0 (16 bytes) (field listeners:) --> java.util.ArrayList@0x870f6660 (20 bytes) (field elementData:) --> [Ljava.lang.Object;@0x888c5720 (72 bytes) (Element 0 of [Ljava.lang.Object;@0x888c5720:) --> org.netbeans.modules.web.project.classpath.WebProjectClassPathExtender@0x870f5080 (28 bytes) (field project:) --> org.netbeans.modules.web.project.WebProject@0x870f1d28 (96 bytes) Static reference from org.openide.loaders.DataObjectPool.POOL (from class org.openide.loaders.DataObjectPool) : --> org.openide.loaders.DataObjectPool@0x86ee2a98 (44 bytes) (field map:) --> java.util.HashMap@0x86ee9d18 (40 bytes) (field table:) --> [Ljava.util.HashMap$Entry;@0x876f4180 (8200 bytes) (Element 1537 of [Ljava.util.HashMap$Entry;@0x876f4180:) --> java.util.HashMap$Entry@0x87dd3e28 (24 bytes) (field key:) --> org.netbeans.modules.masterfs.MasterFileObject@0x870f5620 (21 bytes) (field listeners:) --> javax.swing.event.EventListenerList@0x870fda70 (12 bytes) (field listenerList:) --> [Ljava.lang.Object;@0x88bc3258 (64 bytes) (Element 7 of [Ljava.lang.Object;@0x88bc3258:) --> org.netbeans.modules.web.project.ui.WebViews$LogicalViewChildren$ProjectDirectoryListener@0x88047c80 (12 bytes) (field this$0:) --> org.netbeans.modules.web.project.ui.WebViews$LogicalViewChildren@0x87dd6e08 (77 bytes) (field project:) --> org.netbeans.modules.web.project.WebProject@0x870f1d28 (96 bytes) personally I would say that this should be P2 at least until we explain all these cases and evaluate their impact.
We profiled it with JProfiler and found that the reference was hold by Navigator or Projects windows. After discussion with Tomas Zezula we agreed that it was the same problem as in J2SE project and that there was issue #67849 for that and that was the reason why this issue was closed as a duplicate of #67025. So I don't understand why you reopened it.
And I showed you that there can be various other references - so are you sure that Navigator and projects windows are the only ways? I would se you can't be. Any explanation why the closed web project is held by WebProjectClassPathExtender?
I don't see in the profiler that WebProjectClassPathExtender holds a reference to the closed web project. WebProjectClassPathExtender is held by the web project but not vice versa. ... but maybe I don't know how to use the profiler. Could you give me a short training?
I'm sorry, the reference is held by WebProjectClassPathExtender too. I'm newbie to profiler so I didn't mentioned it.
I see that issues 70150 and 70150 are now fixed, and Petr Blaha says that the leak is now only a few dozen bytes. So should this issue be downgraded to P3?
The memory leak is only 96 bytes per project so I think it could be downgraded but it is up the desision of the performance team because I already downgraded the priority and it was increased immediately back. I don't think there is a big impact of this issue. BTW I found that memory leaks reported in this issue are common for all project types.
I am OK w/ P3. Radko can you file bugs against oher project types (j2se and apisupport I assume)?
TM 5.0->TBD
*** Issue 70161 has been marked as a duplicate of this issue. ***
Using NB 6.0 with GF V2 ur1 b09 To me it looks like there is a memory leak when working with only one web application too! Today I had to make cosmetically changes to one web project ( only .jsp and .css files where involved ). The WAR is part of an EAR (where some ejbs and a number of entities are included). With the WAR three RichFaces jars and apache commons jars are deployed to GF. Because I recognized memory consumption by both NB as well as GF up to a point where my notebook (2 GIG memory) becomes nearly inoperable, I jotted the memory report from Windows TaskManager today. After 5 times RUN Mainproject (the EAR) NB grew from 205 to 326 Megabytes and GF from about 190 to 279 Megabytes. If I would continue, working with NB this way, it would end up at more than 500 MB for each of the two, as I have seen when I was working with beta and rc versions of NB already.
To bernd_zedv@netbeans.org: Could you please generate thread dump of NetBeans? It would be very helpful, thanks. http://wiki.netbeans.org/wiki/view/GenerateThreadDump
Created attachment 54315 [details] the output I got into the console when pressed ctrl-break
In addition to the thread-dump I submitted a few minutes ago here are my observations before I triggered the dump: I started NB and began issuing 5 times a "Run" command on the Ear project whithout changing anything in the code. According to Windows Task Manager, NB's memory consumption grew from 213.780 kb to 280.500 kb while GF grew from 181.432 to 225.360 kb. After that I issued some Undeploy/Deploy and Clean And Build commands where only two blank lines where added to one .jsp file. NB grew up to 359.704 kb while GF came at about 250.000 kb to a stop. Continuing this tests, NB was 429.812 kb and GF 252.884 kb when I triggered the thread dump. When doing more changes to the code, to my experience the figures grow faster and GF looks like being also more involved in growing memory consumption. Thanks, Bernd
Passing to j2ee perf guru.
moving opened issues from TM <= 6.1 to TM=Dev
Is this issue still valid? (reported for 5.0) I would like to close it if there are not any objections...
Issue #70172 is still not fixed.
So let's continue to track the problem under issue 70172, and close this one as WONTFIX - it's really old and contains several unrelated problems. If there are other issues than 70172, let's open new bugs for them.