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 103092 [details] messages.log while NetBeans is trying to load GlassFish projects I'm using NetBeans 7.0beta. I'm trying to use it with GlassFish 3.1. NetBeans 6.9.1 generally works with GlassFish. NetBeans 7.0beta crashes while trying to load the project; it runs out of memory. If I increase the heap size to 1G it quickly uses up all the memory and then keeps running trying to "scan projects". I've left it running for twice as long as it takes to start 6.9.1. It seems that NetBeans 7.0beta is using *a lot* more memory than NetBeans 6.9.1. I've attached the messages.log file.
Bill... I want to get a quick clarification from you... You are one of the GlassFish server developers. Are you creating a java ee project that targets deployment onto GlassFish server or are you trying to open one of the many Maven based Java SE projects that would build an instance of the GlassFish server?
I'm using NetBeans to develop GlassFish itself, not a program that runs on GlassFish.
Thanks, in that case Maven category is more appropriate.
For out of memory conditions it is very useful to attach also a heap dump. I know this file is large but without it the diagnostics is close to impossible. How many projects did you try to open simultaneously? We had a bug report when the user was trying to open several hundreds of subprojects of glassfish...
Unless "Force Quit" on MacOS produces a heap dump, I don't have one. If you can't reproduce this problem yourself, let me know how to get a heap dump and I'll try it again. I have a project group that has the top level GlassFish project and all the subprojects. I don't know how many, but there's a lot. 6.9.1 is able to open the projects.
For howto create a heapdump please have a look at http://wiki.netbeans.org/FaqNetBeansAndOOME I think that the big file cannot be attached to bugzilla - please point us to the file stored somewhere. There was also a request to store the file automagically when OOME happens but I am not sure whether that was implemented or not. BTW was the OOME really shown? I don't see it in the log ... Or was the IDE simply frozen? If it was frozen than thread dump would be usefull, see also http://wiki.netbeans.org/GenerateThreadDump
I assume https://svn.dev.java.net/svn/glassfish-svn/trunk/v3 is the source root? Just tried loading it w/ all subprojects in a NB dev build on Ubuntu x32 with -Xmx768m, seemed OK; resting heap usage around 350Mb. Obviously took a while to scan everything. With a 64-bit JVM I imagine you would want more heap than that since pointers are bigger (supposedly this is planned to be fixed in the future with compact heap pointers). Anyway probably need someone with a Mac to really try to reproduce. BTW I also tried building the tree from the IDE but ran into a compilation error: ejb/ejb-timer-service-app/src/main/java/com/sun/ejb/timers/TimerWelcomeServlet.java:[52,0] package javax.servlet does not exist Might have been a Maven 3 issue, or just an out-of-date source tree.
Created attachment 103122 [details] jmap -histo:live truncated after 1Kb Did see an OOME later, after shutting down, building as much as could be built from CLI (most of the tree), and restarting.
I don't build in NetBeans anymore, too many problems. Try building it all outside of NetBeans, then start NetBeans and let it do all its project scanning and class path scanning. I think it's the huge amount of class file data that causes it to run out of memory. Build instructions are here: http://wikis.sun.com/display/GlassFish/V3FullBuildInstructions
Two things which might reduce memory consumption of metadata: 1. http://jira.codehaus.org/browse/MNG-4860 supposedly can help release some memory after project construction; will try it when integrating 3.0.1 (now in RC). 2. Could hold MavenProject instances (from NbMavenProject) using SoftReference's.
(In reply to comment #10) > MNG-4860 supposedly can help release some memory after project construction Does not work; causes exceptions when there are problems to be reported: java.lang.IllegalStateException: project building request missing at org.apache.maven.project.MavenProject.checkProjectBuildingRequest(MavenProject.java:2195) at org.apache.maven.project.MavenProject.getParent(MavenProject.java:349) at org.netbeans.modules.maven.problems.ProblemReporterImpl.checkParent(ProblemReporterImpl.java:322) at org.netbeans.modules.maven.problems.ProblemReporterImpl.doBaseProblemChecks(ProblemReporterImpl.java:263) at org.netbeans.modules.maven.NbMavenProjectImpl.doBaseProblemChecks(NbMavenProjectImpl.java:534) at org.netbeans.modules.maven.ProjectOpenedHookImpl.projectOpened(ProjectOpenedHookImpl.java:138) It is possible this setProjectBuildingRequest(null) can be safely called if you first force some lazy fields in MavenProject to be initialized by calling getParent and getDistributionManagementArtifactRepository. Whether that would result in a net decrease in memory usage, without a significant increase in project load time, is another question.
Created attachment 103166 [details] jmap -histo:live output Attached is a heap dump of NetBeans trying to load the GlassFish projects. My heap size is set to 1GB. NetBeans very quickly ramped up to using the entire 1GB (as displayed in the toolbar memory usage graph) and then made no progress in over 12 hours of running.
Created attachment 103168 [details] jmap -histo:live output with 1.5GB heap I increased the heap size to 1.5GB. NetBeans quickly increased the heap size to about 1.3GB, where it sat for hours while "scanning projects". Heap dump attached.
I'm here because I googled 'Netbeans 7.0 frozen' This bug describes a similar mine frustrating problem but I'm not using GlassFish now, I developed and maintain a large non conventional standalone EIS Swing/Database based system. But in short many days ago I introduced the next code on one class HashMap <String, String> dHead = new <String, String> HashMap(); Netbeans 7.0 Beta and Java 7 not warned and compiled it. BUT the troubles begining after loading my project and try to modify someting 'Netbeans 7.0 ALWAYS freze'. ONLY today my last desesperate re-re-re-installation with Netbeans 6.91 and compiling 'WITH' java 6 output the next error message D:\NetB\equ\src\equ\ZzdocR0.java:2313: cannot find symbol symbol : constructor <java.lang.String,java.lang.String>HashMap() location: class java.util.HashMap HashMap <String, String> dHead = new <String, String> HashMap(); 1 error I replaced the previous statement with the next and the problem (!Oh my god) finally gone. HashMap <String, String> dHead = new HashMap <String, String>();
I don't believe that's at all related to the problem reported here.
I agree - alvarogh, please file a separate report. Thanks.
Created attachment 105125 [details] Use of MNG-4860; does not seem to make much difference
Created attachment 105127 [details] Uses SoftReference<MavenProject> Seems to substantially improve performance when all 268 GF modules open. Opening all of them still takes some time. Much of the available heap is used most of the time (399M - 676M out of 742M max), but at least some can be freed up for classpath scanning and other operations.
Confirming with a measurement that a fix using MNG-4860 shows no decrease of the enourmous number of org.apache.maven.* objects. So any use of setProjectBuildingRequest() method either with null (while getting all relevant information from the project before doing that) or with any soft-referenced ProjectBuildingRequest is not a way to go. The last Jesse's patch here does show a significant improvement. The number of superfluous org.apache.maven.* objects per one MavenProject does not decrease, of course. But as MavenProject instances can be collected, scanning is significantly faster (having more heap to operate) and the resulting heap after opening and scanning is completed shows less than half the number of live MavenProject instances and the related org.apache.maven.* objects. Jesse, integrate the patch and close the issue fixed. Thanks.
core-main #f781f1c83214
Integrated into 'main-golden', will be available in build *201101220001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/f781f1c83214 User: Jesse Glick <jglick@netbeans.org> Log: #192155: hold MavenProject using a soft ref to free up heap when many projects are open.