> > > @Jan: But surely, hanging the container due to one too many arbitrary > redeployments, renders the whole concept of an application server > rather useless? It's thus much safer to designate a lightweight > container (Jetty, Grizzly...) for each and every application. Also, > restarting a Tomcat cluster with apps using bloated Java frameworks > can easily take 15+ minutes.
This could all work if stuff connected to a classloader wasn't allowed to use strong references. It's just that no one is interested in fixing it 'cos until recently everyone was in denial that it was broken. Now the Oracle guys might have a different view but then to get a new JSR for classloading in a way that doesn't break every container out there.. jigsaw (who knows how that is going to work and the last description I saw was freak'en scary!!!!).. OSGi ( which doesn't follow the model and so is even more broken)... piece mealing a solution together here or having one group try to push one bad hack over the problem isn't really progress. Anyways, my objection to the comments in the podcast is the blaming perm for the problem is akin to killing the messenger. I'd there to be more visibility to the real problem. Regards, Kirk > > > On May 22, 4:10 pm, Jan Goyvaerts <java.arti...@gmail.com> wrote: >> For a desktop application this might make sense. But for an application >> server .... ? >> >> >> >> >> >> >> >> On Sun, May 22, 2011 at 16:03, phil swenson <phil.swen...@gmail.com> 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 <casper.b...@gmail.com> >>> 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 <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. >> >>> -- >>> 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. > > -- > 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. > -- 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.
