Version 3.0 of the JRockit Virtual Machine for Java has been released. JRockit is a family of certified Java Virtual Machines that are specially designed for server-side Java (J2EE) applications. Version 3 brings many notable features including Concurrent Garbage Collection, which eliminates pauses even on gigabyte-size heaps.

JRockit is a high performance, manageable and configurable Virtual Machine for Java. The product is available for Windows, Linux and Solaris (shortly). An evaluation download is available from the website.

Notable features of the 3.0 version is: Concurrent Garbage Collection - eliminates pauses even on gigabyte-size heaps. Management Console - enhances the ability to manage and monitor the Virtual Machine.

JRockit Home Page
Press Release

Their thread implementation sounds interesting. Their "thin threads" sound like sgi's "state threads" (http://state-threads.sourceforge.net/docs/st.html). Can anyone confirm this?

I wonder if they will make any money, given the new i/o in jdk1.4 and the fact that massively-parallel SMPs are not really used in production clusters. I guess it should be great if you happen to have an E10000 ....

Guglielmo

It would be nice to see an ECPerf benchmark run against carefully tuned Sun, IBM, and JRockit server JVM's running on the same hardware/os/J2EE server platform to see the real benefit of this JRockit JVM. JBoss would be a fine platform for testing, IMHO.

Chuck McCorvey

HiHi,

Does anyone have any pricing information? Many thanks.

James

1. Official ECperf results can only be published on J2EE ceritifed app servers. So JBoss is out, but it would be possible to post unofficial results on jboss-dev or wherever, I suppose. <sarcasm>And nothing (except priorities and resources like time, money, and people) stops anyone from running ECperf on their favorite app servers and doing their own internal comparison</sarcasm>

2. ECperf is no picnic to set up, although I've done it on JBoss.

3. JRockit was really unreliable in its previous version (2.x), especially when stopping/starting repeatedly on Windows or running at all on Solaris. Linux was OK, and it was stable on Windows as long as you didn't need to stop and start too often.

4. JRockit is amazingly scalable, all other things being equal. And it's about as fast as Sun's and IBM's implementations of HotSpot.

5. Check the Volano benchmarks page occasionally. They haven't updated since May, but I expect the will for JRockit 3.0: http://www.volano.com/benchmarks.html

> being equal. And it's about as fast as Sun's and
> IBM's implementations of HotSpot.

Hmmm... And what would be the compelling reason to use a costly JVM if it is only ABOUT AS FAST AS free IBM or Sun JVM's?

> 5. Check the Volano benchmarks page occasionally.
> They haven't updated since May, but I expect the will
> for JRockit 3.0: http://www.volano.com/benchmarks.html

One thing that bothers me about the scripts provided to run the Volano benchmark is that they do not tune the JVM's the way I would myself. I have seen remarkably better performance from the Sun 1.3.1 JVM depending on a few arcane settings. I know I can run the benchmark myself, so I suppose I could tweak the scripts and see how that affected things. It would be nice if the published figures were the best possible for each given JVM and platform.

The lack of stability in the previous JRockit JVM releases bothers me. Reliability is the number one thing we should look for in a server-side JVM. Raw performance has to come second.

Chuck

The compelling thing about JRockit for me (assuming they get it stable) is the reduced interruption time afforded by a concurrent garbage collector. The HotSpot garbage collector stops the world and analyzes the entire current generation of the heap. If it doesn't get the memory it wants it analyzes the entire heap, which can take a long time on a server with lots of memory. Even on a SMP machine the GC is single-threaded, so the SMP doesn't help at all. The HotSpot incremental GC helps a lot to reduce the random latencies, but it just breaks the same process into smaller chunks. It still has to stop the JVM while it analyzes.

Some of the JRockit garbage collectors (there are several) are concurrent, so they run in parallel with the rest of the JVM and the overall operation is much more smooth. This means a single JVM can manage a lot more memory while still running without pauses.

 - Nathan

True enough about the concurrent GC. Sun Java 1.4 promises this as well, but I haven't looked into it much.

Chuck

> compelling reason to use a costly
> JVM if it is only ABOUT AS FAST AS
> free IBM or Sun JVM's?

There are reasons, such as that JRockit blows both IBM and Sun away on Linux. I understated the performance on Linux in my previous post. Speed is one thing, but what JRockit has shown repeatedly on Volano marks is that they scale better than any other JVM in terms of multi-threading and socket I/O.

JRockit exposes some cool tuning params that Sun and IBM don't, and they're planning to have more, to give users more control over the JVM.

I think JRockit has potential. As long as they can keep up with the teams at Sun and IBM (no small task) on the basics of speed and scalability, they could continue to provide value-adds specialized for heavy duty server side apps. At JavaOne this year they demo'ed a GUI JVM Console that showed you live metrics in the VM, and provided some dynamic control over the JVM.

On the benchmark front, I have felt that the Spec JVM 98 benchmark was more interesting...

http://www.spec.org/osg/jvm98/results/index.html

...except that, of late, it's become more of an area for the big boys to see if they can top each other on the hardware front.

However, it is interesting to note that the record holder (Compaq Alpha with 32Gb RAM) turns in a benchmark less than double that of a 256Mb Pentium III Dell using the IBM VM on Windows.

It is a shame more that companies like Rocket do not use real benchmarks like Spec or ECperf to promote themselves.

JBB2000 is probably a better benchmark for JRockit. The JVM98 benchmark is almost exclusively single-threaded (the lone exception is the MTRT phase which runs as two threads) and for most of the tests the heap is capped at between 2MB and 20MB, so it doesn't really test scalability or SMP issues.

I too would be interested in seeing ECPerf or SPEC results for JRockit running on a variety of platforms, but I don't know how much that would cost for JRockit. I can only guess that the benchmarks are fairly expensive for the vendors, and JRockit is not a big company.

 - Nathan

As I understand it, other than the $400.00 license fee, the only costs for running and publishing SPEC JBB2000 benchmark results are those associated with getting the hardware you'll need and the manpower to prepare, run/tune and submit the results.

And you are right, a JBB2000 benchmark of JRockit, Sun, IBM and other JVM's on the same SMP platform would be very informative. A 4- or 8-way NT box would yield highly informative results.

Chuck

Where <b>are</b> the bloody ECPerfs anyway ?
Why is it taking BEA,IBM et all so long to produce
results ?

Are all the app server vendors (apart from Borland)
preparing ECPerf tuned versions ?

<I>Why is it taking BEA,IBM et all so long to produce
results ? </I>

I guess they're waiting for hardware to cost less, in order for their price/performance ratio to come close to Borland's one. ;-)
Go Borland!

Does JRockit use Win32 Fibers?

Fibers are sort of like threads. You can learn more
at http://msdn.microsoft.com/