-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck,
On 10/10/2009 9:26 AM, Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Subject: Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars >> >> My direct experience that had led me to believe that ClassLoaders >> keep lists of their loaded Classes is that a WebappClassLoader >> held across a webapp restart (due to inadequate cleanup by the >> webapp) results in all Class objects loaded by that >> WebappClassLoader staying in memory, essentially forever. > > I think you are correct about Tomcat's WebappClassLoader; it has to > maintain the set of the classes it has loaded since it breaks the > normal Java delegation rule, and can't simply ask its parent for the > class. Is that because the primordial ClassLoader will hand-out references to any class already loaded by any ClassLoader, so if null is returned, then the current ClassLoader knows it needs to do its own loading (if it can)? > The JVM itself keeps track (outside of the heap) of all loaded > classes so that classloaders that follow the standard delegation rule > don't have to. Also, the WebappClassLoader has to be able to re-load classes that are updated during runtime. In order to do that, it needs to know what has been loaded and when. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrQjqcACgkQ9CaO5/Lv0PC4RgCgqpflDSRXQhOFI8uXTT7gqghM W+QAnA6iVa3jOdstaKgzAUspXvYSEQOe =gb1k -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
