Henrik Stahl has posted that JRockit for Java SE 6 is generally available for download. This makes JRockit the first known independent implementation of Java 6, and it includes the new Java 6 features, full support for JRockit Mission Control 2.0 (JRockit's runtime analysis tool), and some impressive benchmark numbers. From the post:

- We see a ~10% improvement across the board from the previous JRockit release (R27.1), and much more in some cases - Out of the box performance in particular has received a huge boost - almost 70% on the SPECjbb2005 benchmark If you like these numbers but are stuck using an older Java version - don't worry. The J2SE 1.4.2 and 5.0 versions of JRockit are based on the same JVM bits, so you will see (almost) the same performance with those. Let's just say I believe we can safely claim that we are the fastest 1.4.2 JVM on the planet. By far.

What happened with Intel Itanium version?

The 1.4.2 and 5.0 variants of JRockit R27.2 are supported on Itanium. As to Java 6, support is currently limited to x86 and x86-64. BEA is investigating Java 6 support for other architectures. Henrik Ståhl JRockit Product Manager, BEA Systems

Now that Macs have thoroughly infiltrated the Java developer community, can we expect a Mac (Intel) version any time soon? Sam

Now that Macs have thoroughly infiltrated the Java developer community, can we expect a Mac (Intel) version any time soon?

That would be fun, wouldn't it? ;-) Additional ports of JRockit are added based on customer demand. So maybe if you manage to drum up enough support among BEA customers...?

I would be interested in seeing what kind of maximum heap size you can give it on a 64 bit system. Haven't had much luck getting Sun's past 1.5GB or so..

I would be interested in seeing what kind of maximum heap size you can give it on a 64 bit system.

Max heap size depends on OS and OS configuration, see JRockit docs on this topic. You can usually get up to 2.5-2.8 GB with the 32-bit JVM on a 32-bit OS, and 3.5-3.8 GB on a 64-bit OS. The 64-bit JVM has been tested with up to 3.5 TB (terabytes) of heap.

Haven't had much luck getting Sun's past 1.5GB or so..

JRockit supports larger heaps due to being able to use a non-contiguous memory space for the heap, see this old blog entry for details.

I just downloaded the release and ran some tests. Using my RETE rule engine I ran manners 128 benchmark with 2 different binaries. One is compiled using SUN jdk1.4.2 and the second with Sun jdk1.5.0. The system I'm testing it on is: dell D820 2GM RAM 2.0Ghz Core Duo CPU heap settings: -Xms512m -Xmx512m For some reason, the 1.4.2 binaries finish the benchmark in roughly 6.5 seconds vs 9.5 seconds with 1.5.0 binaries. I've noticed the same result using SUN's jvm to run the benchmark. The one thing I notice is 1.4.2 binaries use 1 core 75%, the second 25%. 1.5.0 binaries run on both cores evenly 50%. Do you have an idea why that happens Henrik? I'm scratching my head wondering why 1.4.2 binaries run faster in both JRockit and Sun 1.5 and 1.6 JVM. peter lin

For some reason, the 1.4.2 binaries finish the benchmark in roughly 6.5 seconds vs 9.5 seconds with 1.5.0 binaries. I've noticed the same result using SUN's jvm to run the benchmark...

Do you have an idea why that happens Henrik? I'm scratching my head wondering why 1.4.2 binaries run faster in both JRockit and Sun 1.5 and 1.6 JVM.

peter lin

Hi Peter, Most likely caused by some class library difference between 1.4.2 and later Java versions. Would be interested in hearing more if you want to follow up - I believe you have my email so feel free to ping me. -- Henrik

For some reason, the 1.4.2 binaries finish the benchmark in roughly 6.5 seconds vs 9.5 seconds with 1.5.0 binaries. I've noticed the same result using SUN's jvm to run the benchmark... Do you have an idea why that happens Henrik? I'm scratching my head wondering why 1.4.2 binaries run faster in both JRockit and Sun 1.5 and 1.6 JVM. peter lin

Hi Peter,

Most likely caused by some class library difference between 1.4.2 and later Java versions. Would be interested in hearing more if you want to follow up - I believe you have my email so feel free to ping me. -- Henrik

I'll send you an email later today with details to reproduce it :) peter

I would be interested in seeing what kind of maximum heap size you can give it on a 64 bit system. Haven't had much luck getting Sun's past 1.5GB or so..

This may be not the problem with JVM per se, but rather with 32-bit system architecture. For example, standard linux kernel on 32 bit system is able to allocate maximum ~1,7GB of memory. I had the same "problem" with Oracle and SGA. Here comes good explanation: http://www.oracle.com/technology/oramag/oracle/05-nov/o65ocp.html See "Implementing a Large SGA" section. I believe similar limitation applies to Windows...

On Linux, i understand BEA on "Red Hat Linux 4.0 AS/ES 64 Bit x86 Hardware" does support upto few TB on memory ...but i wanted to know how much is supported with SUN JDK ? is it true "BEA WLS does not support Sun JDK on Linux." ???

I would be interested in seeing what kind of maximum heap size you can give it on a 64 bit system. Haven't had much luck getting Sun's past 1.5GB or so..

This may be not the problem with JVM per se, but rather with 32-bit system architecture.

A 32-bit architecture has 2^32 ~= 4 GB address space. However, the amount of memory available for the Java heap is limited by 1) how much memory is reserved for the kernel, the JVM binary itself and any shared libraries that are loaded into the same address space and 2) most JVMs require a contiguous memory space, so it can not create a heap larger than the largest free "hole". JRockit does not suffer from #2, so it can often be used with larger heaps than the Sun or IBM JVMs.

For example, standard linux kernel on 32 bit system is able to allocate maximum ~1,7GB of memory.

That would be the old 2.4 kernel. Red Hat EL3 and later and SuSE ES9 and later allows up to 3 GB of process address space in the standard kernels.

I had the same "problem" with Oracle and SGA. Here comes good explanation:

http://www.oracle.com/technology/oramag/oracle/05-nov/o65ocp.html

See "Implementing a Large SGA" section.

I believe similar limitation applies to Windows...

That Oracle document applies to Red Hat 2.1, which is based on the 2.4 Linux kernel. Cheers -- Henrik

Good work, guys, congrats to the team on the release.

great news: tried the beta and found it to be a great product, expecially for the mission control tool which is years light head of jconsole ! new infor about the max memory on 32bit systems is great: expecially useful for web containers with lots of hosted applications. however our obfuscated jars don't work because we do use long class/pakage names and this message appears: java.util.zip.ZipException: name length exceeds 512 bytes sun removed this limit with 1.4.0: isn't it supposed to be resolved for other JDKs too?

however our obfuscated jars don't work because we do use long class/pakage names and this message appears:
java.util.zip.ZipException: name length exceeds 512 bytes

sun removed this limit with 1.4.0: isn't it supposed to be resolved for other JDKs too?

Hi Simone, Sounds like a JRockit limitation. If you can mail me (hstahl AT bea DOT com) a sample JAR that has this issue then we can have it fixed for a later JR release. Or if you have a support contract with BEA, open a support ticket to get a hotfix. -- Henrik

however our obfuscated jars don't work because we do use long class/pakage names and this message appears:
java.util.zip.ZipException: name length exceeds 512 bytes

sun removed this limit with 1.4.0: isn't it supposed to be resolved for other JDKs too?

Hi Simone,

Sounds like a JRockit limitation. If you can mail me (hstahl AT bea DOT com) a sample JAR that has this issue then we can have it fixed for a later JR release. Or if you have a support contract with BEA, open a support ticket to get a hotfix.

-- Henrik

We have found and fixed this. The fix will be in the next JRockit release (R27.3.0), or you can contact BEA Support and ask for a patch for bug id CR319764. -- Henrik

Is there a JRockit VM downloader servlet that supports JNLP clients - i.e. swing clients lauched via WebStart? The downloader servlet controls the VM needed on the client side, OS etc.

Is there a JRockit VM downloader servlet that supports JNLP clients - i.e. swing clients lauched via WebStart?

The downloader servlet controls the VM needed on the client side, OS etc.

JRockit does not include Java WebStart. If you have both the Sun JDK and JRockit installed on the same machine, you can configure JRockit to use the JWS from the Sun installation. This is not something BEA supports or recommends, though ;-)

Anyone know if/when JRockit 6 will be bundled in WebLogic 10?