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 208044 - j2ee.ddloaders build fails on bertram (OutOfMemoryError: PermGen space)
Summary: j2ee.ddloaders build fails on bertram (OutOfMemoryError: PermGen space)
Status: RESOLVED WONTFIX
Alias: None
Product: ide
Classification: Unclassified
Component: Schema2Beans (show other bugs)
Version: 7.2
Hardware: All All
: P3 normal (vote)
Assignee: schema2beans-issues@ide
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2012-02-03 14:55 UTC by Vladimir Voskresensky
Modified: 2015-09-17 13:10 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Voskresensky 2012-02-03 14:55:38 UTC
After pushing annotation based MIMEResolver's into team repos 3 of them can not be built anymore (cnd-main, javaee, web-main):
http://bertram-tst.netbeans.org:8080/

Build fails with 
OutOfMemoryError: PermGen space

i.e. 
[repeat] WARNING: Ineffective registration of resolver resolver.xml use @MIMEResolver.Registration! See bug #191777.
   [repeat] error: Exception thrown while constructing Processor object: java.lang.OutOfMemoryError: PermGen space
  [nbmerge] Failed to build target: all-j2ee.ddloaders

OR
   [repeat] An annotation processor threw an uncaught exception.
   [repeat] Consult the following stack trace for details.
   [repeat] java.lang.OutOfMemoryError: PermGen space
  [nbmerge] Failed to build target: all-j2ee.dd.webservice
Comment 1 Jaroslav Tulach 2012-02-03 16:22:38 UTC
The "WARNING: Ineffective registration" is printed incorrectly. Thanks for the report. Fixed as ergonomics#20894bee95ab

However please note that the error says: "Exception thrown while constructing Processor object: java.lang.OutOfMemoryError: PermGen space" - thus the error cannot be related to MIMEResolverProcessor - if there was an error while constructing it, the above warning would not be printed at all.

If I remember correctly the j2ee.ddloaders build had already had problem with memory in the past. It is possible MIMEResolverProcessor makes the situation a bit worse, but it is not the main culprit.
Comment 2 Jaroslav Tulach 2012-02-03 16:28:59 UTC
The possible way to avoid the memory usage in j2ee.ddloaders is to fork the compiler. Something along the following patch (if nb-javac supported fork):

diff -r 20894bee95ab j2ee.ddloaders/nbproject/project.properties
--- a/j2ee.ddloaders/nbproject/project.properties       Fri Feb 03 17:17:28 2012 +0100
+++ b/j2ee.ddloaders/nbproject/project.properties       Fri Feb 03 17:27:35 2012 +0100
@@ -48,3 +48,5 @@
 test.unit.run.cp.extra=\
     ${masterfs.dir}/modules/org-netbeans-modules-masterfs.jar:\
     ${xml.tools.dir}/modules/org-netbeans-modules-xml-tools.jar
+
+build.compiler.fork=true
diff -r 20894bee95ab nbbuild/templates/common.xml
--- a/nbbuild/templates/common.xml      Fri Feb 03 17:17:28 2012 +0100
+++ b/nbbuild/templates/common.xml      Fri Feb 03 17:27:35 2012 +0100
@@ -202,8 +202,10 @@
         <depend srcdir="${src.dir}" destdir="${build.classes.dir}" cache="${build.dir}/depcache">
             <classpath refid="cp"/>
         </depend>
+        <property name="build.compiler.fork" value="false"/>
         <nb-javac srcdir="${src.dir}" destdir="${build.classes.dir}" debug="${build.compiler.debug}" debuglevel="${build.compiler.debuglevel}" encoding="UTF-8"
-                deprecation="${build.compiler.deprecation}" optimize="${build.compiler.optimize}" source="${javac.source}" target="${javac.target}" includeantruntime="false">
+                deprecation="${build.compiler.deprecation}" optimize="${build.compiler.optimize}" source="${javac.source}" target="${javac.target}" includeantruntime="false"
+                fork="${build.compiler.fork}">
             <classpath refid="cp"/>
             <compilerarg line="${javac.compilerargs}"/>
             <processorpath refid="processor.cp"/>
Comment 3 Jaroslav Tulach 2012-02-03 16:34:09 UTC
This is the memory histogram I see after doing ant -f j2ee.ddloaders/build.xml clean netbeans:

 num     #instances         #bytes  class name
----------------------------------------------
   1:        360180       38210448  [C
   2:        138390       34072144  [B
   3:         37681        9411632  [I
   4:         20287        7226304  [Ljava.lang.Object;
   5:        284611        6830664  java.lang.String
   6:        323826        5181216  com.sun.tools.javac.util.List
   7:         34408        4228960  <constMethodKlass>
   8:         34408        3031264  <methodKlass>
   9:        105997        2543928  java.util.HashMap$Entry
  10:         55856        2418976  <symbolKlass>
  11:         36441        2332224  com.sun.tools.javac.code.Symbol$MethodSymbol
  12:         70658        2261056  com.sun.tools.javac.code.Scope$ImportScope$ImportEntry
  13:         63024        2016768  com.sun.tools.javac.code.Type$MethodType
  14:          3178        1962464  <constantPoolKlass>
  15:         73067        1753608  com.sun.tools.javac.util.ListBuffer
  16:         65932        1582368  com.sun.tools.javac.code.Scope$Entry
  17:         26270        1471120  com.sun.tools.javac.code.Symbol$VarSymbol
  18:          3177        1383168  <instanceKlassKlass>
  19:         12877        1329184  [Ljava.util.HashMap$Entry;
  20:         32959        1318360  com.sun.tools.javac.comp.Env
  21:         76837        1229392  java.lang.Integer
  22:          2634        1214272  <constantPoolCacheKlass>
  23:         37293        1193376  com.sun.tools.javac.tree.JCTree$JCIdent
  24:         14547        1047384  com.sun.tools.javac.code.Symbol$ClassSymbol
  25:         20430         980640  com.sun.tools.javac.zip.ZipFileIndexEntry
Comment 4 Jaroslav Tulach 2012-02-11 19:22:19 UTC
Now I can reproduce the problem reliably (I could not last week). I consider this a proof the problem has nothing to do with declarative MIME resolvers work.

Here is heap dump generated after doing "ant clean build" on revision 34d4c4253a2b: http://netbeans.org/projects/performance/downloads/download/208044-dump.hprof.gz

I am not sure why we run out of perm gen space. I see 1000 of $Proxy classes. Possibly generated by schema2beans and its XSLTs. But that is just a hypothesis. CCing Tomáš. But both me and him are on vacation...
Comment 5 Jaroslav Tulach 2012-02-11 19:24:03 UTC
The failure happens when schema2beans are generating a class (look at the snapshot stack traces):

  
"main" prio=5 tid=1 RUNNABLE
	at java.lang.OutOfMemoryError.<init>(OutOfMemoryError.java:25)
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
	   Local Variable: java.security.ProtectionDomain#723
	   Local Variable: java.lang.String#272218
	at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
	   Local Variable: byte[]#788
	   Local Variable: java.lang.String#272217
	   Local Variable: java.security.CodeSource#742
	   Local Variable: sun.misc.URLClassPath$JarLoader$2#1
	   Local Variable: java.net.URL#4170
	at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
	   Local Variable: java.net.URLClassLoader$1#1
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	at org.netbeans.modules.schema2beansdev.BeanClass.genAccessors(BeanClass.java:668)
	   Local Variable: org.netbeans.modules.schema2beansdev.AbstractCodeGeneratorClass$Signatures#1
	   Local Variable: org.netbeans.modules.schema2beansdev.metadd.MetaProperty#1
	   Local Variable: org.netbeans.modules.schema2beansdev.AbstractCodeGeneratorClass$Property#1
	   Local Variable: java.util.ArrayList#285969
	   Local Variable: org.netbeans.modules.schema2beansdev.metadd.MetaElement#1
	   Local Variable: java.lang.String#272220
	at org.netbeans.modules.schema2beansdev.BeanClass.generate(BeanClass.java:1522)
Comment 6 Tomas Hurka 2012-02-11 20:16:32 UTC
(In reply to comment #4)
> Now I can reproduce the problem reliably (I could not last week).
How do you reproduce it?
Comment 7 Tomas Hurka 2012-02-11 20:37:21 UTC
Here is the list of classloaders sorted by number of loaded classes:


{ loader:java.net.URLClassLoader#1, count:1027, }
{ loader:com.sun.istack.tools.ParallelWorldClassLoader#2, count:861, }
{ loader:com.sun.istack.tools.ParallelWorldClassLoader#1, count:855, }
{ loader:com.sun.istack.tools.ParallelWorldClassLoader#3, count:530, }
{ loader:java.net.URLClassLoader#25, count:469, }
{ loader:sun.misc.Launcher$AppClassLoader#1, count:456, }
{ loader:java.net.URLClassLoader#15, count:428, }
{ loader:java.net.URLClassLoader#24, count:405, }
{ loader:java.net.URLClassLoader#26, count:351, }
{ loader:java.net.URLClassLoader#22, count:350, }
{ loader:java.net.URLClassLoader#17, count:349, }
{ loader:java.net.URLClassLoader#21, count:342, }
{ loader:java.net.URLClassLoader#5, count:339, }
{ loader:java.net.URLClassLoader#4, count:310, }
{ loader:java.net.URLClassLoader#10, count:309, }
{ loader:java.net.URLClassLoader#14, count:309, }
{ loader:java.net.URLClassLoader#18, count:300, }
{ loader:java.net.URLClassLoader#7, count:291, }
{ loader:java.net.URLClassLoader#9, count:287, }
{ loader:java.net.URLClassLoader#16, count:281, }
{ loader:java.net.URLClassLoader#8, count:258, }
{ loader:java.net.URLClassLoader#20, count:253, }
{ loader:java.net.URLClassLoader#19, count:249, }
{ loader:java.net.URLClassLoader#3, count:218, }
{ loader:java.net.URLClassLoader#6, count:212, }
{ loader:java.net.URLClassLoader#23, count:200, }
{ loader:java.net.URLClassLoader#27, count:189, }

Three com.sun.istack.tools.ParallelWorldClassLoader instalces look suspicions. There is also a lot of same classes loaded by different java.net.URLClassLoader - this can be easily seen if you sort classes by name in 'Classes' view and display 'Static Fields', which will show classloader for particular class.
Comment 8 Petr Jiricka 2012-03-28 09:08:02 UTC
Ok, reassigning to schema2beans. The workaround is to increase the PermGen space, so downgrading priority.
Comment 9 Martin Balin 2015-09-17 13:10:21 UTC
Report from old NetBeans version. Due to code changes since it was reported likely not reproducible now. Feel free to reopen if happens in 8.0.2 or 8.1.