Hi,
I also have the same problem, searched the web, read lots of blog
entries and articles of how you can avoid it. The advice found
basically is: increase the memory available for the permgen, and do
not redeploy your application too often.
Am I the only one who is not satisfied with this? In my opinion, the
ever increasing permgen memory consumption in the Sun JVM (I think it
is only 1.6, but maybe also 1.5) is a bug in the JVM design.
The problems that occur have nothing to do with bad programming
practices or buggy application code (although bad practices and buggy
code can increase the problem). Even the best, cleanest application
will show the same behaviour after being reloaded in an application
container for a number of times. And redeploying an application
without restarting the JVM is not such a new, obscure thing that it is
clear there is no support for it.
How is OSGi dealing with this issue (the same problems should occur
there)?
Does any of you know if this issue is addressed in the next, upcoming
versions of the Sun JVM?
Best Regards,
Christoph Jäger
On Mar 17, 2009, at 22:23 , Christian Edward Gruber wrote:
Yeah, I can't remember how they partition. I do believe it is
generational though, but it's been a while. Mostly I try to not
think about it, but I get occasional flashbacks.
Christian.
On Mar 16, 2009, at 9:43 PM, Geoffrey Wiseman wrote:
On Mon, Mar 16, 2009 at 7:07 PM, Christian Edward Gruber <
christianedwardgru...@gmail.com> wrote:
Your behaviour could simply be that the defaults in JRockit are
set such
that you get more permgen space, or that the space is used more
efficiently.
In such a case, you're masking the problem, not resolving it.
I believe the JRockit VM doesn't have a permanent generation
(although I
don't remember if it's a generational garbage collection system).
- Geoffrey
--
Geoffrey Wiseman
http://www.geoffreywiseman.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
