Caldarale, Charles R wrote:
From: Jim [mailto:[EMAIL PROTECTED]
Subject: Re: PermGen Out of memory exception
PermGen space, on the other hand, doesn't get garbage collected
As Peter C indicated, this is utter BS. Why do people keep propagating
this fallacy? Easier to blame the JVM than take responsibility for bugs
in your own code?
Cool, thanks a lot for the clarification, and sorry about that. So
there's nothing in the JVM or Tomcat (possible unknown/unfixed bugs
notwithstanding) that precludes PermGen space from being recovered via
garbage collection when undeploying an application? It's necessarily a
leak in the application or one of the libraries/frameworks it uses?
To address your rhetorical question :) , this issue is a mess to
research. This industry being what it is, it can be intimidating to be
pointed at a 21 page Sun white paper when users are screaming because
the application is down; it certainly makes it hard for me to defend the
learning curve of using Java-based open source approaches when that's
the suggested avenue. People are obviously going to look for the quick
answers first: Tomcat's FAQ (http://tomcat.apache.org/faq/memory.html)
suggests too many servlets/JSPs for the PermGen issue. I use frameworks
rather than servlets/JSPs directly, but when I go to the forums/bugs for
those frameworks, they're usually blaming each other, or Tomcat, or the
JVM. Turning, then, to a couple examples from Google:
- Google "tomcat permgen" and get
http://www.jroller.com/agileanswers/entry/preventing_java_s_java_lang,
which suggests upgrading Tomcat, or switching to JRockit, or upgrading
the JVM.
- Google "permgen error", and get
http://my.opera.com/karmazilla/blog/2007/03/15/permgen-strikes-back,
which says: "And finally, the permanent generation. This is for objects
that the virtual machine has decided to endorse with eternal life -
which is precicely the core of the problem. Objects in the permanent
generation are never garbage collected; that is, under /normal/
circumstances when the jvm is started with /normal/ command line
parameters."
It's hard not to take that last snippet at face value, for example, when
a blank application with a framework stack leaks on reload, and all said
frameworks claim to be leak-free. It's also called /Perm/Gen. The
fallacy's just not obvious, and there's no simple authority on this
common issue.
Perhaps the Tomcat FAQ on memory-issues could be fleshed out/updated?
With so many blogs, forum posts, and bug-report-discussion-threads
suggesting that it's normal to expect an unbounded PermGen increase when
reloading/redeploying applications, an explicit contrary statement in
the FAQ would be helpful, if even to clarify for users that yes, they
/should/ bother doing their own memory-profiling on this issue, because
there /is/ a problem with some code they're using, whether it's theirs
or another party's. The PermGen discussion in the FAQ should be
expanded to include the now-common case of PermGen running out not
because of servlets/JSPs but because of Hibernate's heavy PermGen usage,
or because some other third party is precluding classloader garbage
collection on reload/redeploy (which would be a great place for the link
to Spring's compilation of leak issues with third-party libraries).
Jim
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
