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 -
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 righ
Throwing the classloader away should do the trick. I've done this in
the past with other things.
On 2/14/07, James Carman <[EMAIL PROTECTED]> 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
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 S
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. The
Howard,
Is the permgen space problem solved in T5?
James
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
