Maybe someone should run it through a memory profiler to be sure. But, sounds pretty good. I think we need to make sure that tapestry's class pool doesn't maintain a hard reference to its generated classes. But, if the classloader is thrown away, that might just do it.
On 2/14/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
The "PermGen" problem is elusive, but I think it will be less common in T5. It was caused by the shear volume of classes generated (every component gets a subclass) multiplied by a full reload on every request. T5 is stingier; it only enhances classes once, until some component class changes. Then it throws away all the page instances and the class loader used to enhance them. Now, I can't be certain this fully clears up PermGen, since there's always the question about whether the ClassLoader and all of its classes is being properly relcaimed by the GC (I believe Tapestry is doing its part), but at the very least, we're on the right track. On 2/14/07, James Carman <[EMAIL PROTECTED]> wrote: > Howard, > > Is the permgen space problem solved in T5? > > James > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
