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.
