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 <kirk.pepperd...@gmail.com> 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 javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
