My OperaReturn of the PermGen
Saturday, September 29, 2007 10:38:18 PM
This appears to be the third installment in the saga of my PermGen problems.
For good measure, here are the previous posts:
The newsflash this time is that I stumbled upon some guy Thompson's blog post about this very problem - by itself nothing new; concluding by recommending a JVM with infinite perm-space (BEA or IBM).
The interesting part, however, is stoney's comment where he links to two posts on a blog by Frank Kieviet.
The first of Franks posts is concerned with what the PermGen error is really all about, namely how these leaks in the reloading classloaders in our application servers happen. His second post is a bit more involved and shows how you can use new profiling tools in Java 6 to track down classloader leaks.
So the good news is that we now have the knowledge and tools required to kill this bug.
The bad news is that we've also learned that walking the walk will probably be a lot tougher than talking the talk.
We have to scrutinize our dependency tree, and think really, really, REALLY hard before we put a jar in our servers indorsed directory.
In fact, I think I'll try an experiment tomorrow (today, actually, after I've slept) where I strip down a Tomcat instance (JBoss is probably too intertwined with itself to really strip down) and create some web applications who's only runtime dependencies are the servlet-api and the JRE!
I should really think that classloader leaks are really hard to create with something as simple as the servlet-api, and if you use your JRE with care, then it should damn well be possible to avoid classloader leaks with that dependency as well.
Man, I'm really excited about the idea that there's actually hope for us lay-coders to actually rid ourselves of this nasty ghost-bug-thing/issue.
I'll be sure to report back when I've done some experiments with this new knowledge!
For good measure, here are the previous posts:
The newsflash this time is that I stumbled upon some guy Thompson's blog post about this very problem - by itself nothing new; concluding by recommending a JVM with infinite perm-space (BEA or IBM).
The interesting part, however, is stoney's comment where he links to two posts on a blog by Frank Kieviet.
The first of Franks posts is concerned with what the PermGen error is really all about, namely how these leaks in the reloading classloaders in our application servers happen. His second post is a bit more involved and shows how you can use new profiling tools in Java 6 to track down classloader leaks.
So the good news is that we now have the knowledge and tools required to kill this bug.
The bad news is that we've also learned that walking the walk will probably be a lot tougher than talking the talk.
We have to scrutinize our dependency tree, and think really, really, REALLY hard before we put a jar in our servers indorsed directory.
In fact, I think I'll try an experiment tomorrow (today, actually, after I've slept) where I strip down a Tomcat instance (JBoss is probably too intertwined with itself to really strip down) and create some web applications who's only runtime dependencies are the servlet-api and the JRE!
I should really think that classloader leaks are really hard to create with something as simple as the servlet-api, and if you use your JRE with care, then it should damn well be possible to avoid classloader leaks with that dependency as well.
Man, I'm really excited about the idea that there's actually hope for us lay-coders to actually rid ourselves of this nasty ghost-bug-thing/issue.
I'll be sure to report back when I've done some experiments with this new knowledge!
Unregistered user # Sunday, September 30, 2007 6:28:39 AM
Unregistered user # Sunday, September 30, 2007 6:30:25 AM
Christian Vest Hansenkarmazilla # Sunday, September 30, 2007 9:18:52 AM
And sorry about this stupid blog software; even I can't make your urls clickable it seems.
Unregistered user # Thursday, January 7, 2010 5:26:22 AM