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.
Summary: | ModelSet$ProjectClassLoader memory leaks | ||
---|---|---|---|
Product: | obsolete | Reporter: | Quy Nguyen <quynguyen> |
Component: | visualweb | Assignee: | Winston Prakash <wjprakash> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | sandipchitale, wjprakash |
Priority: | P2 | Keywords: | PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 123530 | ||
Attachments: | Mem leak through com.sun.webui.theme.ThemeReference |
Description
Quy Nguyen
2008-01-11 01:58:14 UTC
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. |