PermGen space is not required by any JVM, in fact IIRC JRockit never had it (not sure about IBMs JVM or others).
It seems an out dated concept (that class data is "special" and all defined well ahead of time to be lazy loaded) which needs to go. But perhaps if there wasn't permgen space, then class leakage (due to classes not being GCed until its classloader is GCed) would look like an ordinary memory leak? (This makes me also think that anonymous classloading could help as well - which I think was part of invokedynamic spec, I vaguely remember) On Dec 20, 2:45 am, Casper Bang <[email protected]> wrote: > I won't even try to pretend that I understand all the intricate > details of the class loaders, GC and leakage. However you turn and > twist it, it's a design issue somewhere between the JVM and the > application server concept (accidental complexity?). And it's one hell > of a good reason to run your app as an embedded Grizzly or Jetty > instead - much more predictable. Now what I would REALLY love to know, > is how on earth is GAE handling this?! > > /Casper > > PS: I have never seen something a kin to PermGenSpace on .NET and I > assume this is due to the fact that they took a more KISS attitude (no > custom low-level class loader, only dynamic assembly modules > responsible for their own mess). > > On Dec 19, 5:49 am, Brian Leathem <[email protected]> wrote: > > > > > On 18/12/09 3:44 AM, Casper Bang wrote: > > > > All good points. Startup time with 15-20 applications deployed would > > > also be more interesting than pure container startup - given how that > > > can easily take 5+ minutes, a long time in a production environment > > > which just suffered from PermGenSpace problems and had to be > > > restarted. > > > How *do* you get rid of those PermGenSpace problems (aside from > > increasing the PermGenSpace). I get them often and have to completely > > restart Glassfish/Netbeans to get back to normal. This can take a > > while, as Glassfish doesn't stop nicely when it runs out of PermGen. > > > I made significant improvements by moving some of my 3rd party Jars into > > the app server lib folder, so that those classes wouldn't have to be > > re-loaded with every re-deploy. But it still happens. > > > Maybe with GF v3 finally having support for compile/deploy on save for > > maven projects, I'll finally escape this problem. > > > Brian Leathem -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
