Skip to main content

Sun JDK 6.0u2 is available

Posted by opinali on July 4, 2007 at 11:08 AM PDT

This is a massive update with 182 fixes and enhancements, including a few performance optimizations that allowed Sun to recover the SPECjbb2005 nonclustered record as reported by David Dagastine. Perhaps due to this many changes, Update2 took some time to be delivered (David's perf report dates from JavaOne, two full months behind us) so it seems like Sun took the extra time to make this a very stable update too.

I particularly like fix 6523674: Allow different styles of java object fields allocation. This improvement makes HotSpot smarter about laying out the fields of objects with inheritance. Elaborating further on the bugtrack commnents, say you have "class A { int x; byte y; }" and "class B extends A { short z; }". Up to 6.0u1, HotSpot would generate the following layouts (ignoring the object header, and assuming 32-bit platform / 4-byte alignment):

 

class A:
--------
0-3:   x
4:     y
5-7:   (padding:3)

class B:
--------
0-3:   x
4:     y
5-7:   (padding:3)
8-9:   z
10-11: (padding:2)

 

The new release is better, it uses free space in the superclass layout when possible (e.g. when the derived class has small fields that fit in some "inherited" padding slot):

 

class B:
--------
0-3:   x
4:     y
5:     (padding:1)
6-7:   z

 

In the example, notice that "z" is a 16-bit field so it only needs to be aligned on a 16-bit boundary. Final result, instances of "B" will be 4 bytes smaller in the new JVM, which makes everything better (allocation/construction time, GC overhead, CPU cache efficiency, locality, etc.). This optimization should be more effective for code with deep inheritance hierarchies, and even better for 64-bit platforms that require 64-bit references and bigger alignment; for example, "class C { Object o; int i; }" results (again ignoring the header) in a packed 8-byte object for 32 bits, but under a 64-bit JVM it expands to a 16-byte object with 4 bytes of padding after "i" (since "int" is always 32-bit regardless of the JVM), so this padding can now be used for small fields of subclasses - and under a 64-bit JVM, most types become "small" (compared to alignment): everything except references, longs and doubles. In short, if you have a big server app that keeps tons of complex objects in memory (e.g. caches of persistent entities), you may observe some significant improvement with this update. Tell me if you find anything.

Other major change is the new packaging of Java DB (née Derby), which is now installed on a separate directory. I like this much better. But the installer created the full "db" directory tree under the JDK installation dir, just without any files - anyone confirm this as a bug? And while I'm at this, Java DB's BAT files for Windows stink. Please give me proper native launchers, just like for all JDK tools. Get rid of those pesky frameworks/VeryLongAndMixedCaseName/bin directories also, I always hated that in Derby, why can't you have a single /bin? And why is full documentation included for Java DB but not for the JDK (I'm not claiming that the docs should be bundled or not -- just that it should be consistent). Java DB is still badly integrated into the JDK, please make it look more like an extension of the JDK and not as some alien project that was just zipped into the JDK installation bundle. Yeah I know Sun has already made the most critical integration work, like testing/validating each release. But they must walk this extra mile to deliver a better developer experience.

Higher in my with list, however, is: please update the installer so the installation of the Java update checker is optional. I hate it, as well as ANY software that (without my explicit consent) installs any kind of preloader, auto-updater, monitor, and other crap that just sucks RAM and "phones home" periodically. This stuff should all be either off by default, or allow the user to switch off in the installer and not after the fact after digging in some configuration tool.