|
|
|
|
Back to newsletter 087 contents
I wasn't looking for a themed newsletter, but I seem to have ended up with one on heap tuning. Starting with Jon Masamitsu's blog entry (from Sun) detailing the GC algorithms available and also giving details of the G1 collector they are working on now - and be sure to read down to the comments where the GC team, in the guise of Tony Printezis, gives detailed answers to various questions.
Then Kirk lays in with his own blog giving his advice on heap tuning - and trust me, Kirk has done a lot of that, so he's well worth reading. And in addition Gregg Sporar reprised and extended his JavaOne presentation on handling OOMEs (for the TheServerSide symposium), with a detailed run through of how to handle them. Naturally we have extracted all the tips, and just those three articles provide over 60 tips, and that's not even considering the other worthy articles we looked at this month.
Worth noting separately is that one of the comments to Jon Masamitsu's blog pointed at another article which showed that garbage collection is faster than explicit memory management - but only if the memory used was five times or greater more than you would use with explicit memory management. My experience of comparing, approximately similarly complex levels of C++ and Java applications indicates to me that your average Java app uses considerably more than five times as much memory than the equivalent C++ app. Put those pieces of information together with Brian Goetz's excellent article ( covered by us ages ago) that shows you both how and why Java memory management is faster than explicit memory management, and you can see why the average memory management overhead of Java apps, at below 10%, is significantly lower than the average overhead of explicit memory management, at over 20%. Of course Java needs extra space to gain that advantage - nothing comes for free. Which do you prefer, automated memory management that is both faster than explicit memory management and less bug prone too; or the smallest possible runtime footprint? Personally, I'll be sticking with Java.
Now on with the newsletter. We have our usual lists of Java performance tools, news, articles, and we also have a new Java performance cartoon from "profiler"; Javva The Hutt tells us about the the I.T. habitat; and, as usual, we have extracted tips from all of this month's articles.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 087 contents
