"- 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."

" 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."

" 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.. "

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

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

" 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."

"JRockit supports larger heaps due to being able to use a non-contiguous memory space for the heap, see "

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

"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.."

"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. "

" 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 ?"

" 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."

"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."

"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."

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

"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..."

"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."

" 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:"

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

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

"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."

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

"Is there a JRockit VM downloader servlet that supports JNLP clients - i.e. swing clients lauched via 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 ;-) "

" Open Terracotta provides Java applications with a runtime environment that allows developers to trust critical parts of heap as reliable and capable of scaling through shared access across multiple machines. "

" While there doesn't seem to be a universally accepted definition of SOA, there are two things that
... read the whole article