Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

News March 2008

Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC tuning

Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:

Training online
Threading Essentials course

Get rid of your performance problems and memory leaks!

Back to newsletter 088 contents

I was using a C# client (not a client I wrote, it connected to a Java server). Its performance sucked. Of course, as I'm not one of those slashdot ranters, I know better than to say it was C#'s fault. It was, of course, that the particular configuration that I was running had not been performance tuned (or even performance tested) - the same is true for anything written in any language. You can get sucky performance from anything - and even well written code can produce bad performance, so I don't even assume that the code was badly written. Any non-trivial app really needs performance testing, and quite probably performance tuning too.

Then the C# client deadlocked. At least I think it deadlocked - it stopped updating the app screen, which went white-ish, and showed the hourglass cursor. It was taking no CPU (from previously maxxing the CPU), and would not refresh at all. It had 40 threads running - or, more precisely, sitting completely idle. My experience is that this very likely indicates a deadlock.

A note from this newsletter's sponsor

Wily Technology delivers what you need: Availability, Performance and Control
The most critical web applications in the world are managed by
software from Wily, the leader in enterprise application management

So, naturally, I asked the dev team behind the client (it was a production client, developed in-house by one of my customers), how to dump the threads so that I could send them the listing of the deadlock. Apparently you can't. Well, you can, but you have to attach something - a debugger I think. Something that I didn't have. You can attach remotely, but that was problematic given where I was and where they were. There isn't any simple mechanism to just get the dump. Coming from the Java world, where we've had cntrl-brk (on windows, and on unix cntrl-\ or kill -3) from practically the very start, this felt like stone age technology. Is C# really that backward, or was it just lack of experience on the part of the dev team? I don't know, I don't do any C# development. I was left distinctly unimpressed with C#. But I'm all for competition. So if Microsoft engineering is reading, I have a suggestion - go and read the Java troubleshooting guide, and make sure a production C# app can do the same types of monitoring or better. It's the difference between a runtime system that is prime time, and one that is not quite ready.

Now on with the newsletter. We have our usual lists of Java performance tools, news, articles, and we also have Kirk interviewing Dan Diephouse on XML performance; Javva The Hutt tells us about the effects of the credit crunch; and, as usual, we have extracted tips from all of this month's articles.

A note from this newsletter's sponsor

dynaTrace software: >> Monitor. Diagnose. Resolve. >>
Get this JavaMazine article about java performance tools and learn
that dynaTrace is the only solution covering profiling, diagnosis and monitoring


Java performance tuning related news.


Java performance tuning related tools.

A note from this newsletter's sponsor

Better code means better software, and JProbe(R) can help. JProbe finds
and fixes code problems in pre-production, and now with a new lower
price it's easier than ever to develop great code. See how.


Jack Shirazi

Back to newsletter 088 contents

Last Updated: 2023-09-28
Copyright © 2000-2023 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us