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.
Build: NetBeans IDE Dev (Build 20130617-ab3512bc7eab) VM: Java HotSpot(TM) 64-Bit Server VM, 23.25-b01, Java(TM) SE Runtime Environment, 1.7.0_25-b15 OS: Linux User Comments: ovrabec: navigating to a method inside jdk sources (inside BasicTreeUI) Stacktrace: java.lang.OutOfMemoryError: Java heap space at sun.text.UCompactIntArray.initPlane(UCompactIntArray.java:160) at sun.text.UCompactIntArray.setElementAt(UCompactIntArray.java:73) at java.text.RBTableBuilder.addOrder(RBTableBuilder.java:342) at java.text.RBTableBuilder.build(RBTableBuilder.java:154) at java.text.RBCollationTables.<init>(RBCollationTables.java:83) at java.text.RuleBasedCollator.<init>(RuleBasedCollator.java:300)
Created attachment 136077 [details] stacktrace
The memory is consumed by Java parsers. Here are the top retained sizes: com.sun.tools.javac.tree.JCTree$JCCompilationUnit 339,035,331 (30.3%) java.util.HashMap 323,386,265 (28.9%) org.netbeans.lib.nbjavac.services.NBParserFactory$NBJavacParser$EndPosTableImpl 319,953,335 (28.6%) There are 3,561 instances of parser and associated classes.
The number of NbJavacParsers could correspond to the number of source files, IMHO. The indexing system contains some counter-measures against running OOM, but it seems the huge compilation task was requested by debugger, so it runs without those safeguards.