On Thu, 23 Jan 2003, Tolles, James wrote:
> Date: Thu, 23 Jan 2003 15:23:05 -0800 > From: "Tolles, James" <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > Subject: RE: Memory leak with ThreadGroups > > I've noticed this when using jswat debugger. Each time we use the > manager app to reload and updated class, we can see a new instace of the > class in the jswat class list - each as a extra little number assigned > to it. Its beyond my skill level but is seems odd that there can be two > instances of the exact same class loaded in the VM? My guess is that the > classloader loads in a new instance that is used but the previous one is > still in the vm - not sure how this is possible. > Classes have to be unique only within a class loader hierarchy, not JVM-wide. For instance, it's perfectly reasonable for two different webapps to have a class named com.mycompany.mypackage.Foo, even if those classes are totally different. Java does not provide any way to remove a previously loaded class from a class loader. The only way to implement webapp reloading, then, is to have Tomcat throw away its reference to the webapp class loader and create a new one. If your application is well behaved (i.e. it doesn't have classes in common/lib or shared/lib that maintain references to things loaded from the webapp), then this will cause the entire webapp to become garbage. If *any* references to *any* classes inside the webapp still exist, though, then essentially nothing from your webapp can be collected. Of course, this should only be an issue during development -- you should not use auto-reloading in a production environment. Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
