@phil: I don't really know. I once asked Miguel about it, but him being unfamiliar with the JVM made it impossible for me to convey the issue to him properly. I suspect it is different on the CLR as it does not have the concept of a classloader (once a class is loaded, it's loaded and never unloaded).
@Jan: But surely, hanging the container due to one too many arbitrary redeployments, renders the whole concept of an application server rather useless? It's thus much safer to designate a lightweight container (Jetty, Grizzly...) for each and every application. Also, restarting a Tomcat cluster with apps using bloated Java frameworks can easily take 15+ minutes. On May 22, 4:10 pm, Jan Goyvaerts <[email protected]> wrote: > For a desktop application this might make sense. But for an application > server .... ? > > > > > > > > On Sun, May 22, 2011 at 16:03, phil swenson <[email protected]> wrote: > > I still don't understand why the JVM was designed to go in a > > hosed/completely F'ed state when it runs out of memory (permgen or > > heap). We need a flag that tells the JVM to allocate as needed. > > > @Casper, is that what the CLR does? > > > On Sun, May 22, 2011 at 6:52 AM, Casper Bang <[email protected]> > > wrote: > > > You should probably have forked a new discussion of this. Anyway, I > > > don't claim to understand the intricate detail of what exactly causes > > > memory to leak through classloaders and PermGen space to skyrocket. I > > > just know that is *IS* a real problem that one can not redeploy and > > > app to an application container, without the risk of having the JVM > > > crash (usually silently), with all applications hanging > > > unresponsively! > > > > Oddly enough, it's not a concept known in the Android or Mono world. > > > Are you saying then that, even with the PermGen removed in JDK7, we'll > > > still suffer the same problems just manifested in different ways? And > > > if so, in which ways? > > > > /Casper > > > > PS: I often wondered how GAE handles this issue. > > > > On May 22, 12:19 pm, Kirk <[email protected]> wrote: > > >> Hi all, > > > >> Nice plug for JRebel/Zero turn-around. Jevgeni and the lads in Estonia > > have really put together a great product and it's amazing that they've been > > able to find their own hack/fix for the classloader leak. If anyone was > > going to do it.. these guys needed to 'cos as you said, having to restart > > your VM because of the perm space problem really suxs. > > > >> But, to blame it on perm space is misleading. *ALL* JVM's no matter if > > they have perm space or not leak classloaders. This includes Azul, IBM, HP, > > JRockit and of course Sun/Oracle. This is because the real problem is a > > result of the complex relationships that exist between classes, instances of > > those classes, extensions of those classes, implementations of interfaces > > mixed in with application servers and the tiered delegating class creates. > > Long story short, the Java 2 class loader model that is broken. Perm Space > > is fundamentally good as it's intent is to partition away objects from the > > collectors. > > > >> For example, if you have a application class implementing an interface > > from the bootstrap classloader, it is possible that this relationship, which > > is expressed in the object reference chains, will keep your classes metadata > > live. Because your class is live, the classloader that loaded it will be > > live. Since the classloader is live, *all* of the classes referenced by that > > classloader will be kept live. Which means in the context of an application > > server, that products logic may "unload" an application and reload the new > > version but that intricate little reference chain from the bootstrap > > classloader (or the extension or the application or another tiered loader) > > will prevent everything from being GC'ed. > > > >> Note, no mention of perm space this description of the problem. The Perm > > Space problem is that being a separate memory pool in the JVM, the > > classloaders leak is contained. This is bad because that space is limited > > and you will reach it fairly quickly. But it's also good in that perm space > > leaks tend to have very little impact on GC pause times. > > > >> Regards, > > >> Kirk > > > > -- > > > 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. > > > -- > > 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. -- 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.
