On 4/21/05, Caldarale, Charles R <[EMAIL PROTECTED]> wrote: > > From: Peter Lin [mailto:[EMAIL PROTECTED] > > Subject: Re: OutOfMemoryError - 100 thread limit? > > > > so it would appear by setting the PermSize, the jvm is pushing all > > java.lang.Class instances to Perm rather than loading them in eden and > > then promoting them to tenured. > > Instances of java.lang.Class are always allocated in the perm gen, never > in an eden space, regardless of any heap or gen size settings.
logically, it makes sense that all java.lang.Class classes are loaded in Perm. But the result on the behavior LeeAnn saw is a bit perplexing. I'm just exploring here, so if it doesn't make sense, it's cuz I'm making wild guesses. ie, talking out of my rear. the default Perm is 64M. If LeeAnn's webapp have a large number of classes, maybe there's too many; therefore forcing the VM to resize the perm. Doing that, the VM probably is allocating a big block and copying all the data over. I believe that is much heavier task than an incremental GC and probably equally costly as a full GC. So once the new Perm is ready, the VM should make the old block available. So the end result of setting -XX:MaxPermSize is it avoid resizing Perm, which allows Tomcat to load the webapps quickly. Even though setting max Perm to 128 reduces the overall space for new/old generation, it results in better performance because the VM doesn't have to move perm? of course this is assuming the VM prefers to have a continuous block for Perm memory. > I believe that's true, since static data is associated with > java.lang.Class instances. > > - Chuck > peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
