What happens is that every class *referenced* by each Java class to be enhanced also becomes a CtClass.
The fix may be something for HiveMind, to use a WeakHashMap for the CtClass instance cache. But Javassist may be caching them as well. On 10/6/05, Patrick Casey <[EMAIL PROTECTED]> wrote: > > 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] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
