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.

Bug 238307 - OutOfMemoryError: GC overhead limit exceeded
Summary: OutOfMemoryError: GC overhead limit exceeded
Status: RESOLVED WONTFIX
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 7.4
Hardware: All All
: P3 normal (vote)
Assignee: Svata Dedic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-13 11:24 UTC by jaleo
Modified: 2016-07-07 07:17 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 205219

Attachments
stacktrace (1008 bytes, text/plain)
2013-11-13 11:24 UTC, jaleo 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description jaleo 2013-11-13 11:24:38 UTC 
Build: NetBeans IDE 7.4 (Build 201310111528)
VM: Java HotSpot(TM) 64-Bit Server VM, 23.7-b01, Java(TM) SE Runtime Environment, 1.7.0_17-b02
OS: Windows 7

User Comments:
jaleo: I was debuggin a program.




Stacktrace: 
java.lang.OutOfMemoryError: GC overhead limit exceeded
   at java.lang.String.substring(String.java:1913)
   at java.lang.ClassLoader.checkCerts(ClassLoader.java:924)
   at java.lang.ClassLoader.preDefineClass(ClassLoader.java:657)
   at java.lang.ClassLoader.defineClass(ClassLoader.java:785)
   at org.netbeans.JarClassLoader.doLoadClass(JarClassLoader.java:284)
   at org.netbeans.ProxyClassLoader.selfLoadClass(ProxyClassLoader.java:259)
Comment 1 jaleo 2013-11-13 11:24:39 UTC 
Created attachment 142125 [details]
stacktrace
Comment 2 Antonin Nebuzelsky 2013-12-27 16:14:48 UTC 
A ton of problems logged from java.source. Reassigning for evaluation.
Comment 3 Svata Dedic 2014-08-29 20:03:43 UTC 
If I see correctly, there are 5 instances of JavaCompiler, instances #4 and #5 directly in a thread frame (= compiler executing), instance #3 kept from executing NbClassReader in JavadocEnv.

Instances #1, #3 and #4  are kept also through JavaSourceUtil.Handle. EditorContextImpl references WeakHashMapActive, values of the Map.Entries are JSU.Handles that keep Compiler in memory. As long as a single EditorContextImpl lives, all compilers are IMHO hard referenced.

Instance #5 is kept by a strange reference:

CompilationInfo#4 -> JavacParser#2 -> CompilationInfoImpl#3 -> JavaCompiler#5.

so one culprit is (I think) the debugger.jpda.projects, keeping potentially many JavaCompilers through the WeakHashMapActive alive.

Dusane, could you please investigate the intermixed references between CompilationInfoImpl, JavacTask, JavacParser ?
Comment 4 Martin Balin 2016-07-07 07:17:08 UTC 
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss