The changelog for mustang build 81 shows tiered compilation as being completed (done and fixed in the 'new features' section). Tiered compilation means that both the client-mode and server-mode compilers are present in the same VM, such that code can be compiled quickly by the client-mode compiler, but further optimized with the server-mode compiler if needed.

The client compiler is faster than the server-mode compiler, but the server-mode compiler normally generates better code. It's not clear how the memory adjustments made by choosing the client or server compilers are addressed by tiered compilation.

Has anyone run this build and validated that this feature is really there? Has anyone seen any performance benchmarks of the new tiered compilation system?

The bug report says this is only for Solaris, not Windows :(

For more info see:

http://www.javagaming.org/forums/index.php?topic=13429.0

and

http://blogs.sun.com/fatcatair/20050826

Mike

*lol*

This is what JRockit has done for years. It has a "quick-and-dirty" JIT and then an optimizing compiler that is used on hot methods. The only difference is that it doesn't have an interpreter (which explains the longer startup times). Still, I fire up WLS with JRockit in ~20 seconds on my old laptop and that includes JIT compiling some 20,000+ methods, so maybe it's not that bad :D

Anyone know how J9 does it? I seem to recall IBM having a multi-tiered compiler now.

*lol*This is what JRockit has done for years.

Perhaps, but every time I tried JRockit it crashed soon after the start when Sun's JVM kept working...
Matter of perception, but I have WAY more confidence in Sun's JVM than in any other JVM out there.

Perhaps, but every time I tried JRockit it crashed soon after the start when Sun's JVM kept working...Matter of perception, but I have WAY more confidence in Sun's JVM than in any other JVM out there.

Strangely enough, this is the same experience I have had with JRockit; it just won't stay up.

Can you specify the version of JRockit encountering such behavior ?

Thanks,

GR.

Can you specify the version of JRockit encountering such behavior ?Thanks,GR.

I could not tell the exact version or build. I remember trying a couple of versions during the JDK 1.4.2 era. I have not tried the latest versions so perhaps the situation has changed since then.

The versions that I did try, all crashed on me regularly so I had to give up using them.

I was running web publishing with a couple of thousand JSP templates, running Tomcat. The batch jobs were running for maybe 5 hours every night, JRockit just never made it through. As far as I could tell, the dumps I was getting were all about Java threading. I did not analyze it further.

Later versions of JRockit are significantly more stable than a few years ago. I frequently hear from people who have switched from the Sun JVM because they experience that JRockit is better for their apps. One example of an old issue with the Sun JVM is PermSpace tuning, which is not needed with JRockit (nor J9, IIRC).

However, I would not use this as an argument that JRockit is more stable than Sun (or IBM). All major JVMs are very mature products by now. I think it's more a matter of "different JVM, different bugs".

Henrik, BEA JRockit team

Perhaps, but every time I tried JRockit it crashed soon after the start when Sun's JVM kept working...Matter of perception, but I have WAY more confidence in Sun's JVM than in any other JVM out there.

Strangely enough, this is the same experience I have had with JRockit; it just won't stay up.

<disclaimer> I'm a BEA engineer </disclaimer>

Not so strangely for me, I have the opposite experience. I've been using JRockit as an engineer for awhile now. I have not had any serious problems whatsoever. I routinely run builds and the application I work on for several hours at a time, sometimes running builds overnight. Of course I've also had similar experience with Sun JDK. But I've been using JRockit for at least the past year exclusively.

 Granted different environments may yield different results, but I'm running it on Windows XP SP2 laptop with 2GB Ram.

Perhaps, but every time I tried JRockit it crashed soon after the start when Sun's JVM kept working...Matter of perception, but I have WAY more confidence in Sun's JVM than in any other JVM out there.

Strangely enough, this is the same experience I have had with JRockit; it just won't stay up.

We recently moved our webserver to the latest JRockit and that far we are very happy with it. Not that it is crash free (nor either any other JVM in our experience), but everything is running very fast and I really like the autonomic memory management of JRockit. It makes life easier.

Anyone know how J9 does it? I seem to recall IBM having a multi-tiered compiler now.

You can find some info about IBM JVM 5.0 (bases on J9) at http://download.boulder.ibm.com/ibmdl/pub/software/dw/jdk/diagnosis/diag50.pdf

Ciao, Diego

J9 has been able to recompile at higher optimization for quite some time (as well as AOT compilation). Nothing to see her folks...move along....

I've tried JRockit a number of times, and have had various problems with it. A long time ago, it was extremely fast, but crashed extremely fast too. Then, it didn't work with CGLIB which is what we use for our AOP madness. I hear that CGLIB is used in some other moderately popular frameworks too. Now that works (thanks to BEA support for that), and I just now managed to get our portal product running on JRockit for the first time, with the latest JRockit.

Only to have it barf on XStream. Now, in some sense this is XStream's fault, but since XStream is reasonably popular as far as a XML-handling tool, it would be very much appreciated if some BEA engineer sacrificed the three hours needed to create a reflection converter for JRockit that works similar to the Sun JDK converter. Please pretty please! For my own purposes that seems like the last obstacle to use JRockit.

Tax declaration day is coming up here in Sweden and we won't be able to get JRockit in this year, but it would be great if next year the Swedish IRS website runs on JRockit. Don't you think?

Mail me at hstahl at bea dot com and we'll see what we can come up with.

Cheers!

...and for the record: XStream uses sun.misc.Unsafe which is just a horrible way to code and strongly discouraged by Sun. Unfortunately this bad habit is fairly widespread, so JRockit (and IBM, IIRC) has been forced to implement parts of that API to maintain "bug compatibility" with Sun.

I wish, oh I wish, that Sun had *never* made that API public!

I have submitted a patch to XStream with a cleaner use of Unsafe. This will enable "Enhanced Mode" with recent JRockit versions.

http://jira.codehaus.org/browse/XSTR-311