I think there is only a single instance of a generated class created for each page visit. However, I would have now doubt that just bringing up Tapestry would create 600+ classes. I've since deleted the original e-mail, I will go dig it up to see if each page visit was generating instances. Hmmm, found the original e-mail seem's like a large number of generate classes. Might be time to investigate using jmp and a small application. In cache and non-cache mode.
If you haven't used jmp, check it out at http://www.khelekore.org/jmp/. It's a free memory profiler that works really well. The only caveat is that you must install gtk+ if you want to use it under Windows. The other way you can use it is install it on Linux and use an X server. I've had success with both. I will poke around with JMP and a small application to see what I turn up anything. Richard -----Original Message----- From: Patrick Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, October 06, 2005 10:30 AM To: 'Tapestry users' Subject: RE: OutOfMemoryError Tapestry 4.0 Isn't the major source of the OP's memory use though the 600+ new instances of javassist.CtNewClass in the classes hashmap per page load? Are you thinking that a simple page with two property selects on it ought to require 600+ support classes to back it, because that sounds about two orders of magnitude too high to me. Are you sure there's not some sort of underlying bug in javassist and/or Howards implementation thereof? --- Pat > -----Original Message----- > From: Hensley, Richard [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 06, 2005 10:24 AM > To: Tapestry users > Subject: RE: OutOfMemoryError Tapestry 4.0 > > Generated Classes are loaded into a class loader so they can be > instantiated > by Tapestry and Hivemind. The only way to release the generated classes is > to release the class loader. > > I tried once to evict classes from a ClassLoader while I was doing some > Groovy stuff, according to the ClassLoader specification, it's not > possible > to evict a class. After you think about it for a while, you come to the > conclusion that this is a good thing. > > I think that Hivemind and Tapestry load the generated classes into the > same > class loader that owns the parent class of the generated class. This class > loader can not be released because it is owned by the application > container. > So, the real question is why are some many classes being generated. The > flag > noted by Howard below causes a class to be generated each time a page with > abstract properties is visited. When running in production, my experience > is > that the classes only get generated the first time they are needed. > > So, the next avenue of investigation is to figure out what the actual > generated classes are that were being reported as part of CtClass by the > memory leak tool. > > Richard > > -----Original Message----- > From: Leonardo Quijano Vincenzi [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 06, 2005 10:10 AM > To: Tapestry users > Subject: Re: OutOfMemoryError Tapestry 4.0 > > Howard Lewis Ship escribió: > > >That might be reasonable if you are running with > >-Dorg.apache.tapestry.disable-caching=true > > > >With caching disabled, Tapestry has to constantly create new enhanced > >subclasses for every page and every component. > > > > > Shouldn't it delete old classes? > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
