Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 240150 - OutOfMemoryError: GC overhead limit exceeded
OutOfMemoryError: GC overhead limit exceeded
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Maven
7.4
All All
: P3 (vote)
: 8.0
Assigned To: Milos Kleint
issues@projects
EXCEPTIONS_REPORT
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-09 09:45 UTC by Exceptions Reporter
Modified: 2014-01-16 02:43 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
stacktrace (312 bytes, text/plain)
2014-01-09 09:45 UTC, Exceptions Reporter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Exceptions Reporter 2014-01-09 09:45:56 UTC
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)
Comment 1 Exceptions Reporter 2014-01-09 09:45:58 UTC
Created attachment 143742 [details]
stacktrace
Comment 2 Tomas Hurka 2014-01-09 09:54:39 UTC
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.
Comment 3 Milos Kleint 2014-01-14 12:56:10 UTC
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.
Comment 4 Quality Engineering 2014-01-16 02:43:36 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo