-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck,
As always, thanks for correcting my misunderstandings of the JVM and GC. Caldarale, Charles R wrote: > All instances of java.lang.Class are allocated within the PermGen from > the get-go; there is no migration into or out of PermGen. (The tenured > generation does operate as you describe.) I didn't realize that. I guess the JVM figures that Class objects need not actually earn their tenure, since they are likely to be loaded for a long time. Nice optimization. >> I'm a little hazy on PermGen, actually, but I think it >> /never/ gets cleaned up. > > Not true, except if one esoteric, non-standard GC algorithm is selected > for the HotSpot JVM. PermGen is cleaned up whenever a full collection > occurs. I thought a lot of the talk on this list about PermGen was that it was filling up and never being cleaned-up. Maybe that was just folks legitimately keeping lots of data around for a long time. >> Second, class loading and GC are mostly unrelated > > Not true - they're intimately connected. I disagree. Loading a class into memory from bytes doesn't interact with the GC any differently than loading an array of bytes from any other file. The only connection between them would be through the JIT, which needs to know that it's okay to free compiled-code-memory when the Class object becomes collectible. ClassLoaders themselves don't have any magic in them. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG4XU+9CaO5/Lv0PARAjbgAKCHwbLHH5NqkCWKoc8zZg4NbhYpfgCeJ7GN 2uMnvqYazd/OkDYQMqskqg8= =3qek -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
