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.
The project classloader constructed by insync appears to be leaking. To reproduce: * Make sure the Outline never opened 1) Create a vw project 2) Drop a component 3) Clean-Build 4) Close the project 5) Repeat steps 1-5 as needed 6) Open/close the properties window (avoid another memory leak) Every instance of ModelSet$ProjectClassLoader is still retained in memory after these steps.
Some of the leaks are through javax.faces.FactoryFinder which is managed from within the FacesContainer (jsfsupport). Winston should probably have a look. One leak is through Keep-Alive-Timer thread. Need to investigate this.
Here is the GC root path to one of the leaks: org.netbeans.modules.visualweb.insync.ModelSet$ProjectClassLoader@45356a[...]: private static java.lang.ClassLoader org.netbeans.modules.visualweb.jsfsupport.container.FacesContainer.staticLoader-> org.netbeans.modules.visualweb.insync.ModelSet$ProjectClassLoader@45356a
Some info on KeepALiveCache leak. http://opensource.atlassian.com/confluence/spring/display/DISC/Memory+leak+-+classloader+won't+let+go
Two other leaks seem to be through: - com.sun.webui.theme.ThemeReference (see attached profile references window screeen shot showing GC root) - com.sun.org.apache.commons.logging.LogFactory.
Created attachment 55213 [details] Mem leak through com.sun.webui.theme.ThemeReference
Do not use the static class loader in FacesContainer hack. Instead use the Thread.currentThread().getContextClassLoader() to look up classes at designtime. Checking in src/org/netbeans/modules/visualweb/jsfsupport/container/FacesContainer.java; /cvs/visualweb/jsfsupport/src/org/netbeans/modules/visualweb/jsfsupport/container/FacesContainer.java,v <-- FacesContainer.java new revision: 1.9; previous revision: 1.8 done Checking in src/org/netbeans/modules/visualweb/insync/java/ClassUtil.java; /cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/java/ClassUtil.java,v <-- ClassUtil.java new revision: 1.4; previous revision: 1.3 done
The remaining leaks are in FactoryFinder and LogFactory.
Looking at the possibility of resetting the commons logging factory via reflection. Testing now ..
Resetting the memory held by com.sun.org.apache.commons.logging.LogFactory. using reflection.
The memory leak looks like it still exists with the following steps: 1) Create a vw project 2) Drop a component 3) Clean-Build 4) Delete the component 5) Clean-build 6) Repeat steps 1-5 as needed 7) Close the project The Runtime watches window will show a ProjectClassLoader every time the 'Refreshing Models' action is run. The references are also not cleared when the project is closed. org.netbeans.modules.visualweb.insync.ModelSet$ProjectClassLoader@1ce0da9[urls=[...]]: private static final java.util.Map javax.faces.FactoryFinder.applicationMaps-> java.util.HashMap@1c3307d-table-> [Ljava.util.HashMap$Entry;@1b7a237-[2]-> java.util.HashMap$Entry@a92d33-key-> org.netbeans.modules.visualweb.insync.ModelSet$ProjectClassLoader@1ce0da9
After properly setting the classLoader before calling FactoryFinder.releaseFactories, now that seems to be fixed. But I see a new problem. private static final java.util.Set com.sun.faces.config.ConfigureListener.LOADERS-> java.util.HashSet@79c12f-map-> java.util.HashMap@ffac-table-> [Ljava.util.HashMap$Entry;@99527c-[12]-> java.util.HashMap$Entry@951e6e-key-> org.netbeans.modules.visualweb.insync.ModelSet$ProjectClassLoader@4d2ecd Along with this I still see reference by ThemeReference (send an e-mail to Rick Ratta) java.awt.EventDispatchThread@7a2f0-threadLocals-> java.lang.ThreadLocal$ThreadLocalMap@e5fce3-table-> [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@ac9cbe-[426]-> java.lang.ThreadLocal$ThreadLocalMap$Entry@d75942-value-> com.sun.webui.theme.ThemeResources@6db133-themeReferences-> [Lcom.sun.webui.theme.ThemeReference;@e6d0cf-[0]-> com.sun.webui.theme.ThemeReference@89c01a-classLoader-> org.netbeans.modules.visualweb.insync.ModelSet$ProjectClassLoader@7357b3
I fixed the classloader held by private static final java.util.Set com.sun.faces.config.ConfigureListener.LOADERS using configureListener.contextDestroyed(new ServletContextEvent(context)); both during FaceContainer.setClassLoader() and FacesContainer.destroy(). However, every time the project is cleaned and built, the classloader is accumulating at protected static java.util.IdentityHashMap org.netbeans.modules.visualweb.insync.ModelSet.sets-> java.util.IdentityHashMap@7b51b1-table-> [Ljava.lang.Object;@ef47fc-[1]-> org.netbeans.modules.visualweb.insync.models.FacesModelSet@e306db-classLoader-> org.netbeans.modules.visualweb.insync.ModelSet$ProjectClassLoader@ef290a Assigning this to Sandip to investigate.
The last memory leak Winston has added is not a leak through the reference chain that is shown in the comment. He had not closed the project...so the FacesModelSet should exist which should hold on to the current classloader. Winston did observe the leak of ModelSet$ProjectClassLoaders but they are due to some other references which need to be looked at dealt with.
The last leak is through com.sun.webui.theme.ThemeResource which Winston has a fix for.
Fixed and checked in the reference removal from com.sun.webui.theme.ThemeResource changeset b08f88d7741a in main details: http://hg.netbeans.org/main?cmd=changeset;node=b08f88d7741a With the above fix I no longer see any ModelSet$ProjectClassLoader memory leaks (after proper GC). So marking this as fixed.