Well, yes and no. As I understand the problem, it really got bad around
the Java 5 timeframe because of the addition of Enumerations to the
language. What Resin does (and all auto-reloading Java containers do) is
to create a ClassLoader that contains all the code for your application.
When it senses a change to your code, it loads that new code into a brand
new ClassLoader and releases the old one to be garbage collected once it's
done processing it's active requests. The problem is that, since
Enumerations are guaranteed to work with the == operator, even when
serialized/deserialized between different computers, Java treats them
special, by keeping them in the Permanent Generation (so their internal
ID's won't change). Unfortunately, each time the app is loaded a new set
of Enumerations takes up more space in the precious PermGen until it
finally blows its lid. So, theoretically, you could use less PermGen by
limiting Enumeration use, but that's really not a realistic response.
Before Java became property of Oracle, there was some talk about fixing
this problem at the JVM level, but I haven't heard anything in quite a
On Tue, Apr 24, 2012 at 1:54 PM, Rick Mann <rm...@latencyzero.com> wrote:
> When I'm making changes to the code of a webapp, Resin kindly reloads it
> for me. I can usually get a handful of reloads in before Resin complains
> about being out of PermGen space.
> Is there something I'm doing wrong in my app that it leaks like this?
> resin-interest mailing list
resin-interest mailing list