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.
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
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.
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"/>
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
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...
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)
(In reply to comment #4) > Now I can reproduce the problem reliably (I could not last week). How do you reproduce it?
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.
Ok, reassigning to schema2beans. The workaround is to increase the PermGen space, so downgrading priority.
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.