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.
This issue was reported manually by thurka. It already has 1 duplicates Build: NetBeans IDE 7.4 (Build 201310111528) VM: Java HotSpot(TM) 64-Bit Server VM, 24.45-b08, Java(TM) SE Runtime Environment, 1.7.0_45-b18 OS: Windows 7 User Comments: GUEST: Created a Maven Java application, then tried to create a JFrame and Netbeans hung. Not sure what exactly went wrong though. Stacktrace: java.lang.OutOfMemoryError: GC overhead limit exceeded at java.lang.String.toCharArray(String.java:2753) at java.lang.Thread.setName(Thread.java:1160) at org.openide.util.RequestProcessor.enqueue(RequestProcessor.java:619) at org.openide.util.RequestProcessor$TickTac.run(RequestProcessor.java:2243)
Created attachment 143742 [details] stacktrace
It looks like the OOME is caused by 'Add dependency'. There are 4 "org.netbeans.modules.maven.nodes.AddDependencyPanel" threads. There is java.util.TreeMap#466, which has retained size close to 600M. java.util.TreeMap#466 is a local variable in one of those AddDependencyPanel threads.
the affected big map is triggered via the groupid completion recalculation where for some reason (based on the content of the index at hand) the fast method (precached in index) failed and the slow method kicked in (which eventually led to OOME) 2 solutions I can see. 1. get rid of the slow method. The fast method should only fail in cases of indexes created by very old maven-indexer codebase. Probably better to fail fast rather then die a painful OOME death. 2. a lot of the content in the map can be traced to OSGI related manifest content that is dropped into the lucene documents. There's cases of osgi import/export attributes that are 200k+ in size. We don't effectively query any of the osgi content, so avoiding to store and retrieve it from the index should do no harm. That will both reduce the CPU and memory requirements at both indexing and searching times. http://hg.netbeans.org/core-main/rev/5cc878ddb9e7 includes both solutions.
Integrated into 'main-silver', will be available in build *201401160001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/5cc878ddb9e7 User: Milos Kleint <mkleint@netbeans.org> Log: #240150, #239915 avoid slow search for groupids, it's a memory bottleneck. Also avoid storing and retriving osgi related document fields, we do not query them and they can occupy a lot of memory