Hitting the memory ceiling doesn't mean you have a bug or memory leak. Usually it's because you haven't figured out the right JVM settings. The current approach means you have to take guesses with -Xmx and -XX:MaxPermSize until you find the magic number that doesn't cause your application to crap out. I'm not advocating getting rid of these settings, I'm just advocating having an option that allocates as needed.
I can't count the # of times QA or a customer has come to me saying the application is hosed. And they send me the logs. I see OutOfMemory and I respond "try -Xmx=1200m".... Even my IDE craps out because of this and I have to go edit a script file somewhere. Default settings should handle the 95% case. And I argue 95% of the time the behavior people want is "allocate as needed." On Sun, May 22, 2011 at 10:18 AM, Kirk <[email protected]> wrote: > 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. > > -- 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.
