A troubleshooter's view on the IBM JDK vs "the other guys"
JohnPape 0600007J6A Visits (8964)
I'll preface this post with two facts: 1. I'm an IBMer and I am not impartial to WebSphere and IBM Javatm, and 2. my primary job function involves solving (sometimes extraordinary) customer problems. That aside, what I wanted to discuss in this post is a comparison between the serviceability capabilities of the IBM JDK and what we'll call: "the other guys". "The other guys" will suffice for a description of any non-IBM Java SDK for the purposes of this post.
This post will not be an all inclusive resource for the differences between the two JDK implementations. What I want to cover are some of the strengths of the IBM JDK over "the other guys" and why you should care. So let's get on with it:
I think you can see here that the serviceability that the IBM JDK provides far outweighs that of "the other guys". But let's not stop with Java dumps, next topic...
Verbose garbage collection logging
The IBM JDK handles this in a much more user-friendly way. For each garbage collection cycle you get a real time stamp value like this:
<sys id="7649" timestamp="Jan 24 16:59:36 2011" inte
Having this actual time stamp value allows you to easily correlate the garbage collection activity to other system logs allowing you to determine how your JVM was performing at an exact point in time. I can't tell you how many times I've been faced with a customer trying to correlate poor JVM performance with a spike in response times from their load generator tool only to have to guess exactly when the garbage collection cycles actual ran because they were using one of "the other guys" JDKs! It's maddening and in most cases you have to result to something like a cron job that echos the outpout of the “date” command into the verbose garbage collection log just so you can get an approximation of times. Again, a huge failure on the part of "the other guys" JDKs in terms of serviceability in my opinion.
So, we're at two strikes now, right? Right. So on to strike three...
Object allocation size
<af type="nursery" id="1846" timestamp="Wed Mar 02 00:03:08 2011" inte
In the example above, the allocation failure was triggered by some Java code requiring an object of 24 bytes in size. If you were using one of "the other guys" JDKs, you would have zero insight into the allocation sizes. None, nada, zip, nil. As far as I know, there is no way to get this information easily, furthermore, the IBM JDK has command line parameters that allow you set a allocation size threshold where, if exceeded, a Java stack trace is printed allowing you to see what code asked for the object that broke the threshold size limit. No such love from "the other guys". And again, as far as I know there is no way to get this data from the JVM by any means (including custom JVMTI, JVMPI, or JVMMI agents/interfaces).
Hopefully, I've been able to show no less than three really good reasons for you to consider using the IBM JDK over "the other guys". When it comes to serviceability it's pretty clear (at least to me) that the IBM JDK handily beats "the other guys" JDK in most, if not all, aspects. But don't just take my word on it, download a copy of the IBM JDK and check it out for yourself!