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.
Created attachment 98124 [details] Heap dump screenshot I was working with several projects: - Maven Java EE 6 Enterprise application - Maven Java EE 5 Web application - NetBeans module project (Ant-based) I was trying to deploy the Java EE 5 WebApp to WebLogic, and a OOME appeared. I have a heap dump which I can provide. After opening the heap dump and computing retained sizes, I saw the biggest objects (255 MB) were Maven-related. I am attaching the screenshot of the heap dump analyzer.
Created attachment 98199 [details] Maven repository tree I am attaching the contents of my Maven repository - currently it's 900 megabytes.
I opened entire GlassFish in current 6.9 dev build (JavaSE 20100427) and was happy it succeeded with default memory settings and ended with < 250MB on heap. Knowing others had problems with this I tried to invoke the indexing of maven local repository (in Options > Misc > Maven) - because it sometimes may run automatically. After it finished I had about 110MB more on heap which did not go down on GC. I have heap dumps both before/after running the indexing.
I also tried with Java SE build (actually, with full IDE ergonomics build and made sure I did not enable any other features than Java SE). Here are the exact steps: 1. Opened a couple non-Maven projects (APISupport) to warm up the Java parsing infrastructure, memory usage went up to 250 MB. 2. Created an ordinary Maven project. The IDE started to index my local repository, memory usage went up to 430 MB. 3. Did GC, memory went down to 360 MB. 4. Created heap dump, computed retained sizes. Again, org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl#1 is taking up 257 MB. 5. After some more work in the IDE, memory suddenly went down to 140 MB. So, not quite as bad as when I got the OutOfMemoryError, but still quite bad to have 250 MB taken up by the indexer.
Confirming the huge retained memory is caused by local maven repository indexing. My measurements have shown roughly ~25megs of heap retained after my local repository has been indexed (size of ~/.m2 is 180megs), and for pjiricka's repository which I have copied (size is 972megs) it was ~160megs retained. The heap occupation is roughly linear to the size of the repo. One bad effect is that it occupies the memory until next full-indexing or at least index update happens, another bad effect is that if some other memory intensive task is running at the same time, it competes for heap and can end up with OOME as reported in this issue. Making embedder and repository references in our NbIndexCreator component weak and allowing them to be collected and refreshed several times during the indexing resolves both bad effects for me. The large resulting retained heap is eliminated and the indexing also requires much less heap during its execution. The resulting local repo index seems unaffected by this change. http://hg.netbeans.org/core-main/rev/654dd9e01c78
Integrated into 'main-golden', will be available in build *201005050200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ User: Log:
great, thanks.
Petre, can you verify that this fix helps? I think you were the only one able to reproduce memory problems with opening the GlassFish project.
Possibly this particular problem is fixed now, but after working with Maven projects for a while, I am getting other problems such as bug 185688 and bug 185847, the IDE generally feels slow and memory usage is around 400 MB, so I am not comfortable confirming that the memory usage is fixed completely/sufficiently.
> I am getting other problems such as bug 185688 and bug 185847, > the IDE generally feels slow and memory usage is around 400 MB, > so I am not comfortable confirming that the memory usage is fixed > completely/sufficiently. The bugs mentioned here are not maven related. Both are related to self-profiling feature. Let's not mix all memory related issues into this one. > Possibly this particular problem is fixed now Good. Thanks for verification.
v.
*** Bug 176292 has been marked as a duplicate of this bug. ***
*** Bug 177625 has been marked as a duplicate of this bug. ***
*** Bug 185230 has been marked as a duplicate of this bug. ***