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.
Summary: | Memory leaks in web projects. | ||
---|---|---|---|
Product: | javaee | Reporter: | _ pcw <pcw> |
Component: | Code | Assignee: | issues@javaee <issues> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | bernd_zedv, dkonecny, gtzabari, issues, johnjullion, pjiricka, pslechta, rkubacki, tmysik |
Priority: | P3 | Keywords: | PERFORMANCE |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 70172, 85817, 128661 | ||
Bug Blocks: | 99077 | ||
Attachments: | the output I got into the console when pressed ctrl-break |
Description
_ pcw
2005-12-07 23:43:41 UTC
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. |