You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by James Carman <ja...@carmanconsulting.com> on 2007/02/14 15:48:59 UTC
[T5] PermGen Problems Fixed?
Howard,
Is the permgen space problem solved in T5?
James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [T5] PermGen Problems Fixed?
Posted by Jesse Kuhnert <jk...@gmail.com>.
Yeah, good point. I guess the trick isn't so much in being "able" to
do it as it is designing the API in such a way as to make a "best
attempt" at preventing people from screwing things up. (ie leaky
abstraction)
I guess we'll just have to see how it works out. (though maybe you're
right James - doing a jprofiler or some other form of object watching
may be a good sanity check step..)
On 2/14/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> What often trips you up is some forgotten ThreadLocal (listing Spring
> guys) that holds a reference to some forgotten object, which holds a
> reference to its own Class and ClassLoader.
>
> HiveMind and Tapestry 5 IoC have all that machinery to avoid using
> ThreadLocals, since they are tricky to get right (especially in a
> managed environment like a servlet).
>
> On 2/14/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> > Throwing the classloader away should do the trick. I've done this in
> > the past with other things.
> >
> > On 2/14/07, James Carman <ja...@carmanconsulting.com> wrote:
> > > 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 <hl...@gmail.com> 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 <ja...@carmanconsulting.com> wrote:
> > > > > Howard,
> > > > >
> > > > > Is the permgen space problem solved in T5?
> > > > >
> > > > > James
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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: dev-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > Jesse Kuhnert
> > Tapestry/Dojo team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [T5] PermGen Problems Fixed?
Posted by Howard Lewis Ship <hl...@gmail.com>.
What often trips you up is some forgotten ThreadLocal (listing Spring
guys) that holds a reference to some forgotten object, which holds a
reference to its own Class and ClassLoader.
HiveMind and Tapestry 5 IoC have all that machinery to avoid using
ThreadLocals, since they are tricky to get right (especially in a
managed environment like a servlet).
On 2/14/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> Throwing the classloader away should do the trick. I've done this in
> the past with other things.
>
> On 2/14/07, James Carman <ja...@carmanconsulting.com> wrote:
> > 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 <hl...@gmail.com> 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 <ja...@carmanconsulting.com> wrote:
> > > > Howard,
> > > >
> > > > Is the permgen space problem solved in T5?
> > > >
> > > > James
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > 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: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [T5] PermGen Problems Fixed?
Posted by Jesse Kuhnert <jk...@gmail.com>.
Throwing the classloader away should do the trick. I've done this in
the past with other things.
On 2/14/07, James Carman <ja...@carmanconsulting.com> wrote:
> 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 <hl...@gmail.com> 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 <ja...@carmanconsulting.com> wrote:
> > > Howard,
> > >
> > > Is the permgen space problem solved in T5?
> > >
> > > James
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [T5] PermGen Problems Fixed?
Posted by James Carman <ja...@carmanconsulting.com>.
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 <hl...@gmail.com> 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 <ja...@carmanconsulting.com> wrote:
> > Howard,
> >
> > Is the permgen space problem solved in T5?
> >
> > James
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [T5] PermGen Problems Fixed?
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <ja...@carmanconsulting.com> wrote:
> Howard,
>
> Is the permgen space problem solved in T5?
>
> James
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org