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.
