 |
Sun JDK 6.0u2 is available
Posted by opinali on July 04, 2007 at 11:08 AM | Comments (11)
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.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
That sounds great! I'd also like to know more about 6536652: Implement some superword (SIMD) optimizations and what these are capable of..
Posted by: zero on July 04, 2007 at 05:17 PM
-
Sun make u2 available at sun.com site for now, but at java.net u2 is available since april, 12.
Posted by: claudio on July 04, 2007 at 06:53 PM
-
zero: I would also love to have more details about that improvement. I wouldn't get too excited because the title seems like a first step, low hanging fruit thing. So, perhaps future updates will have some serious SIMD optimizations. This is sorely missing in JVMs, it's a major point of disadvantage to native languages - even if your C compiler doesn't suport smart auto-vectorization optimizations, you can easily write a few inline assembly macros, or use libraries like these from Intel. But Java programmers are left in the cold, that's a major reason why things like media codecs cannot be written in pure Java with competitive performance. Perhaps we could make good use of a library of intrinsic functions, or annotations to guide the optimizer.
Posted by: opinali on July 04, 2007 at 07:02 PM
-
claudio: I know, but java.net's build is b02. The final, official Update2 is b05. If you scan through u2's release notes you will find a large number of post-b02 fixes. I'm a subscriber of Sun's CAP program and the last update I got was on b03, there was no info about b04/b05 even in the CAP mailing list, so I guess these two builds were internal builds having only low-risk stabilization changes, things like 6567260 : Set SheetCollate attribute to COLLATED and UNCOLLATED not working in 6u2 which seems to be a fix for a regression bug introduced in the first u2 builds. Never use those java.net builds for production; the show is not over until the fat lady sings, or in this case, until the official build appears at java.sun.com ;-)
Posted by: opinali on July 04, 2007 at 07:13 PM
-
somewhat random question: Is there a mailing list or rss feed someplace that announces official JDK updates? I have a perl script that scrapes java.sun.com every morning and works fine, but if there was an annouce list....
Posted by: timeck on July 05, 2007 at 11:01 AM
-
I know I will be labeled as a heretic but I think Java's auto-update is a *very* good idea and should be installed enabled by default.
From the point of view of desktop developers it is absolutely critical to have users running off the latest JRE. JRE updates are far and between and (in my opinion) far less annoying that the constant upgrades you get from Apple or Adobe.
As a concession to Pinali maybe we should allow users to disable this feature at installation time (list it alongside "optional fonts" or something).
Gili
Posted by: cowwoc on July 05, 2007 at 01:00 PM
-
cowwoc: As a Java developer (and one who loves to use always the latest stuff!), it's also my best interest that users keep up to date. But I was blogging as an end-user. I know that JRE updates are delivered only every several months, and the Java Update checks for new versions only every week by default. But the problem is its implementation. At least on Windows, it keeps a jusched.exe process running all the time, and using some RAM for no reason. (I know it's just a couple of megabytes, but I am obsessive with system performance - my system tray is completely empty, well except for LogMeIn as I often work remotely; I disable all Windows services I don't need, my virtual workspace is clean and tidy like a good hospital).
Question: why can't Java Update rely on the system-specific scheduler, like Windows' Task Scheduler or Unix's cron? Then it wouldn't take any resources when not needed. If you worry about Windows users who disable the Task Scheduler service (like I used to do up to WinXP), make that change at least for Vista, where this service cannot realistically be disabled (since Microsoft used it for several system tasks).
Posted by: opinali on July 05, 2007 at 02:05 PM
-
Another advantage of using the system scheduler is that the task could run with elevated privileges and thus not need UAC to perform the upgrade.
Posted by: mthornton on July 06, 2007 at 04:12 AM
-
Interesting thoughts on Java DB and Apache Derby... Regarding the Derby bits, you wrote:
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.
Scripts (as all other code) are handled in the Apache Derby community, which I am sure will appreciate suggestions for improvements. Can you be more specific as to what is stinky about the .bat files? Just the fact that they are .bat, not .exe?
Get rid of those pesky frameworks/VeryLongAndMixedCaseName/bin directories also, I always hated that in Derby, why can't you have a single /bin?
The frameworks directory has already been deprecated, and a bin directory has been added. The frameworks directory is still there though, but will most likely be removed in a future Derby / Java DB release.
Posted by: johnemb on August 16, 2007 at 02:02 AM
-
John, maybe I'm mistaken but I think Osvaldo meant to say that the .BAT files should not be copied as part of the scripts if the targeted platform of installation is Unix (.SH).
Osvaldo, this is good feedback on Derby and as John mentioned, it would be great if you could post your thoughts at derby-user@db.apache.org
(http://db.apache.org/derby/derby_mail.html)
Posted by: forsini on August 16, 2007 at 05:27 AM
-
johnemb, forsini: Thanks for the tip, I will repeat these comments in the Derby list. It was not clear to me if these issues would be relevant to the main Derby project or if it was Sun's responsibility (JDK integration).
The problem with BAT files is that they are second-class citizens in the Windows OS. Windows is not Unix, it's not a script-friendly system. Scripts have important disadvantages. For example, on Windows Vista, if I have a shortcut to a native executable I can bring its property dialog and change compatibility and security (run as admin) settings. These options are not available if the shortcut points to a BAT/CMD script. Other problem: BATs cause a console window to appear, which is just gross if the app doesn't use the console (background daemon or GUI program). And EXEs can have an embedded icon, so the launchers will look cool in Explorer views, but BAT files will all be presented with the same dull BAT icon. Finally, this is not a Derby-targeted criticism, but I see that many portable apps that have launch scripts for Unix and Windows will only have well-written scripts for Unix - the BAT ones are usually an afterthough (as most developers prefer *nix and know their bash much better than CMD), missing fine details like using "start javaw" instead of "java" to launch a GUI app without opening yet another useless console window. These are all reasons why Sun provides native launchers for all JDK tools - and this leads us to the last argument: homogeneity. JavaDB should use native launchers just because the rest of the JDK does that, even if there was no other reason.
Posted by: opinali on August 16, 2007 at 06:22 AM
|
java.net RSS Feeds
