-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
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Subject: Re: Garbage Collection and Class unloading
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
Can someone explain a little bit about classloading really quick?
Let me preface this with: I am maintaining an application which I did
not develop.
Looking at the WEB-INF/lib directory, it has around 76 different jar
files, some actually used in the application, some (well, most) not.
They
On 9/6/07, David Smith [EMAIL PROTECTED] wrote:
I'd think your best bet is to clean out all the dead
in-house code and then thin out the dependencies until it stops
building. If nothing else, refactor your code to pair down the multiple
versions of libraries.
Oh, don't you worry, me and
Others with more experience in the garbage collection may chime in, but
it's my impression that the garbage collection tends to have it's own
mind. You can try to force it, but that's no guarantee it will garbage
collect anything. I'd think your best bet is to clean out all the dead
in-house
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Subject: Re: Garbage Collection and Class unloading
This used to happen because Class objects were never
discarded by the JVM.
That's not true, at least not since JVM 1.2 came into use. Class
objects are discarded once there are no more
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
Brian Munroe wrote:
Looking at the WEB-INF/lib directory, it has around 76 different jar
files, some actually used in the application, some (well, most) not.
They either pertain to legacy features or are functionality duplicate
(two
