393 perigean and stack size

80 views
Skip to first unread message

Kirk Pepperdine

unread,
Sep 7, 2012, 6:01:14 AM9/7/12
to java...@googlegroups.com
Hi all,

Just finished listening to 393 while on my way back home from Zurich. I've been watching the removal of PermGen and I have to say that I'm not all the excited about it leaving us. Dick mentioned that reloading applications into TomCat could fill up perm space. Indeed it does but the old app you've replaced should be GC'ed.. but it can't be because of dreaded classloader leaks. And that is only one scenario where a developer, doing nothing wrong, ends up leaking classes into perm space. I should point out that IBM's JVMs and JRockit, neither of which have permgen also suffer from this classloader leak problem. The problem is; those classes leak into general heap space and this degrades GC throughput while it fills up heap until eventually you degrade into Full GCs and the OOME. WIth Perm Gen you run out of memory (sooner) but in a way that doesn't degrade performance while it's happening. Removing Perm Gen is fixing the symptom, not the problem.ac

Not exactly what you're looking for but there is a Thread constructor that allows you to set Java stack size. The problem with native stack is that it's sandwiched between text and C heap. You'd have to move C heap to dynamically change the size of a stack frame and although we can do that for stuff in Java heap... I don't know how you'd do it generically in C heap. But again, this problem would be mute if proper support for recursion was put into the JVM.

-- Kirk

Casper Bang

unread,
Sep 8, 2012, 5:51:28 AM9/8/12
to java...@googlegroups.com
Yes, it was not clear from the discussion that the problem is a design issue within the JVM and that removing PermGen really just pushes the problem to another generation. I'd love a deep dive into this issue by the The Posse and/or guests. It's a little pathetic/scary that if you redeploy a Java app one too many times to a container, it may blow up (typically stop responding at all and needing a kill -9). It makes me question the whole container aspect and instead deploy with embedded light-weight containers (Jettt/Grizzly).

/Casper

Fabrizio Giudici

unread,
Sep 9, 2012, 5:04:34 AM9/9/12
to java...@googlegroups.com, Casper Bang
On Sat, 08 Sep 2012 11:51:28 +0200, Casper Bang <caspe...@gmail.com>
wrote:

> Yes, it was not clear from the discussion that the problem is a design
> issue within the JVM and that removing PermGen really just pushes the
> problem to another generation. I'd love a deep dive into this issue by
> the
> The Posse and/or guests. It's a little pathetic/scary that if you
> redeploy
> a Java app one too many times to a container, it may blow up (typically
> stop responding at all and needing a kill -9). It makes me question the
> whole container aspect and instead deploy with
> embedded light-weight containers (Jettt/Grizzly).

I'm using extensively Jetty (6) for more than one year for all my
websites. I had to increment PermGen as well (explicit PG OOM error). I
don't have other PG problems related to redeploying since I seldom
redeploy (and at the moment I have another problem related to a periodical
explosion of sockets in the CLOSE_WAIT state that force me to restart
jetty).


--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

Casper Bang

unread,
Sep 9, 2012, 7:25:10 AM9/9/12
to java...@googlegroups.com, Casper Bang
So basically you agree, that the whole app-server/container model, for practical purposes is broken in Java? You can be lucky enough that you have a small enough app or a big enough memory pool for it not to matter, but once an application is loaded into a running JVM, it will leak and resources can never get reclaimed again until it is shut down.

/Casper

Fabrizio Giudici

unread,
Sep 9, 2012, 11:49:52 AM9/9/12
to java...@googlegroups.com, Casper Bang
On Sun, 09 Sep 2012 13:25:10 +0200, Casper Bang <caspe...@gmail.com>
wrote:

> So basically you agree, that the whole app-server/container model, for
> practical purposes is broken in Java?

Well, no, I disagree :-) There are issues, but there are thousands of
servers around working.

Casper Bang

unread,
Sep 9, 2012, 12:04:52 PM9/9/12
to java...@googlegroups.com, Casper Bang
Yeah, there are also thousands of people who claim they have seen Elvis! :)

Ricky Clarkson

unread,
Sep 9, 2012, 12:47:23 PM9/9/12
to java...@googlegroups.com, Casper Bang

I think you might be mixing Elvis and Object Oriented Programming up.  Elvis was real, thousands of people actually saw him.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/KpoQyU9deCgJ.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

Casper Bang

unread,
Sep 9, 2012, 2:02:34 PM9/9/12
to java...@googlegroups.com, Casper Bang
I knew I should've chosen bigfoot instead. :)

Kirk Pepperdine

unread,
Sep 10, 2012, 12:25:24 AM9/10/12
to java...@googlegroups.com, Casper Bang
I'd of gone with bigfoot myself... or Elvis at last years New Years eve party...

That said, there are 1000s of app's running in this some what broken environment. Class loading in multiple classloaders creates a ton of circular references of things stuck in collections. It's a perfect storm for a leak.

-- Kirk

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/HtVLngvhsWcJ.
Reply all
Reply to author
Forward
0 new messages