then you'll eventually run out of memory when all free space is consumed and I think this is a case where you want a fail fast mechanism rather then lets let thing go bad for a hell of a long time before we learn about it.
Think of it this way, GC is run to failure where failure is defined as failure to collect. That implies the cost of GC is heavily influenced by the number of survivors. That is the first cost. There are many other ripple effects on performance for having objects survive longer than necessary. Regards, Kirk On May 22, 2011, at 4:03 PM, phil swenson 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.
