-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck,
On 10/9/2009 7:14 PM, Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Subject: Re: tomcat 5.5.25 shared lib and sharing webapp jars >> >> PermGen is a place where Class objects often end up > > Not often - always (in a HotSpot JVM); and not "end up" - they are allocated > there from the start. Note that PermGen is an attribute of the HotSpot JVM; > most other JVMs do not have a PermGen. Quite true: I was confusing PermGen with the tenured generation. I forgot that PermGen is basically not part of that. It's poorly named because it's not really a generation per se, but is still called a generation. >> The webapp itself is irrelevant. A java.lang.Class object (and >> therefore any code, static members, etc.) can only be dumped from >> memory when the ClassLoader that loaded it is not referenced by >> any live object and no live objects are referring to it. > > That is not true; classes can be unloaded when all instances of the class are > unreachable. One additional requirement: the java.lang.Class object itself must also be unreachable. 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 have forgotten what sloppy practices we had in our webapp at one time, but they have been fixed so we can reload our webapp all day long and not worry about busting PermGen. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrQhWgACgkQ9CaO5/Lv0PCZNgCfYWUqlmZW2D1My/Lz9iiO/rhT T2cAn0Qs/JNBJ3WF2AEcf65kygzwKS1i =PWj6 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
