> 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
-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 te
> 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 discard
-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 dif
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
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
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 eithe
