BEA WebLogic JRockit 5.0 is JDK available for download from www.bea.com/download

It also includes a newly introduced Technology Preview for 64-bit Intel Xeon (EM64T) platform.

•For more information on specific release contents, please review the Release Notes

•Read the press release

Details:

•JRockit 5.0 is freely available for all customers to use and deploy for production use. It is also bundled as part of the WebLogic Server 9.0 (Diablo) Beta release.

•Compatible with J2SE 5.0, JRockit 5.0 offers advanced features that make it (1) simpler and faster to configure and deploy, and (2) easier to manage and diagnose problems with applications during run-time.

•JRockit 5.0 incorporates adaptive memory management, which can allow the JVM to automatically reconfigure garbage collection strategies on the fly and continually adapt its settings over time in order to help consistently maintain a desired throughput and pause time for running applications. This ultimately help eliminates the need for more complex and time consuming tuning exercises.

•JRockit 5.0 will also incorporate real-time memory leak detection capabilities with the next update release allowing developers to diagnose memory leaks in their applications within hours instead of weeks. This capability has been introduced as a Technology Preview in the latest JRockit 1.4.2_05 release. More information can be found in the JRockit Documentation

•JRockit 5.0 also uniquely takes advantage of hardware performance counters available on the Itanium 2 processors to more accurately profile and optimize application performance in order to deliver up to 10-15% higher performance.

•JRockit 5.0 is currently certified and supported on the following operating systems for Intel (and compatible) platforms:

•IA32 (32-bit OSs) – Windows 2000, Windows 2003, Windows XP (dev use only), Red Hat Enterprise Linux 3.0, SuSE Linux Enterprise Server 9.0

•Xeon EM64T (64-bit OSs) – SuSE Linux Enterprise Server 9.0 (Tech Preview)

•Itanium (64-bit OSs) – Windows 2003, Windows XP (dev use only), Red Hat Enterprise Linux 3.0, SuSE Linux Enterprise Server 9.0

•For a complete list of supported platforms, visit the certified configurations documentation Support for additional operating systems will be added with the next update release.

It seems as if the link to the documentation is broken...

Regards
/Par

Mentioning Xeon EM64T and not mentioning x86 AMD64 is a bit shame.
EMT64 is clone of x86 AMD64 and forced Intel's answer to it that hurts Itanium and IA64 very much.

Mileta

No support for opteron 64-bit?

When they say Intel Xeon EMT64, that means it supports Opterons and Athlon 64.

But they should realy say that they support AMD64 as this was AMD's inovation (although not breathtaking, sure). Intel just copied it and give it new name: EMT64. Btw. Sun, in it's JDK 5.0 release, was honest and has given AMD credit for x86 64 support. It seems that BEA's relationship with Intel is strong .

Btw. Sun, in it's JDK 5.0 release, was honest and has given AMD credit for x86 64 support. It seems that BEA's relationship with Intel is strong .

Sun sells AMD64 boxes .. a lot of them. Also, Sun maintains a mostly competitive stance against Intel, although Sun sells Xeon servers too.

Intel helped quite a bit (financially and technically) with the original Itanium support in jRockit. Yes, BEA and Intel have a strong relationship.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

I think I'm gonna have to run some benchmarks for myself and see how it performs. The last time I compared JRockit against Sun and IBM jdk1.4 it was faster than both.

All my tests so far show that JRockit beats the crap out of the Sun JVM performancewise, but so far I haven't managed to get it to work together with CGLIB (some nasty reflection problems), and since we use CGLIB everywhere... well... it's too bad really.

Do you have any benchmarks that proves this?

Do you have any benchmarks that proves this?

For any definition of "prove" the answer would be "no".

Do I have tests that indicates this? Sure, enough for me to switch from HotSpot to JRockit if/when it works with CGLIB.

Remy and I ran several hundred benchmarks and JRockit was faster. I forget if those numbers got into my article on tomcat's resource page. I might still have those numbers around, but they're old so it's better to run a completely new set. only catch is taking the time to do it.

Most recent Hibernate/CGLIB fail on it (I checked Win32 version):

SEVERE: CGLIB Enhancement failed
java.lang.ExceptionInInitializerError
at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)

Maxim Kramarenko,
TrackStudio - Hierarchical Bug Tracking Software

I would say that the problem is in the way CGLIB is doing instrumentation. So that s a CGLIB bug.

You probably know that shipping a VM requires thousands of tests to be run, and that at the opposite, it is failry easy to corrupt some bytecode thru instrumentation.

Probably Chris can give it a look, and then all projects using CGLIB may have to wonder how they could upgrade...

I have started to have a look, and it seems to fail when CGLIB has prepared some proxy named
"$java.lang.Object$$FastClassByCGLIB$$3f697993"
and tries to instantiate it f.e. when running the following code:
at net.sf.cglib.core.ReflectUtils.newInstance(Ljava.lang.reflect.Constructor;[Ljava.lang.Object;)Ljava.lang.Object;(ReflectUtils.java:???)
at net.sf.cglib.core.ReflectUtils.newInstance(Ljava.lang.Class;[Ljava.lang.Class;[Ljava.lang.Object;)Ljava.lang.Object;(ReflectUtils.java:???)
at net.sf.cglib.reflect.FastClass$Generator.firstInstance(Ljava.lang.Class;)Ljava.lang.Object;(FastClass.java:???)
at net.sf.cglib.core.AbstractClassGenerator.create(Ljava.lang.Object;)Ljava.lang.Object;(AbstractClassGenerator.java:???)
at net.sf.cglib.reflect.FastClass$Generator.create()Lnet.sf.cglib.reflect.FastClass;(FastClass.java:???)
at net.sf.cglib.proxy.MethodProxy.helper(Ljava.lang.ClassLoader;Ljava.lang.Class;)Lnet.sf.cglib.reflect.FastClass;(MethodProxy.java:???)
at net.sf.cglib.proxy.MethodProxy.create(Ljava.lang.ClassLoader;Ljava.lang.Class;Ljava.lang.Class;Ljava.lang.String;Ljava.lang.String;Ljava.lang.String;)Lnet.sf.cglib.proxy.MethodProxy;(MethodProxy.java:???)
at net.sf.cglib.transform.impl.TestEnhancerTransform$$EnhancerByCGLIB$$13578f43.CGLIB$STATICHOOK1()V(<generated>:???)
at net.sf.cglib.transform.impl.TestEnhancerTransform$$EnhancerByCGLIB$$13578f43.<clinit>()V(<generated>:???)

And it fails with:
Caused by: net.sf.cglib.core.CodeGenerationException: java.lang.IllegalAccessError-->runFinalizer
at net.sf.cglib.core.ReflectUtils.newInstance(Ljava.lang.reflect.Constructor;[Ljava.lang.Object;)Ljava.lang.Object;(ReflectUtils.java:???)
at net.sf.cglib.core.ReflectUtils.newInstance(Ljava.lang.Class;[Ljava.lang.Class;[Ljava.lang.Object;)Ljava.lang.Object;(ReflectUtils.java:???)
at net.sf.cglib.reflect.FastClass$Generator.firstInstance(Ljava.lang.Class;)Ljava.lang.Object;(FastClass.java:???)


Alex

it fails with:Caused by: net.sf.cglib.core.CodeGenerationException: java.lang.IllegalAccessError-->runFinalizer at net.sf.cglib.core.ReflectUtils.newInstance(Ljava.lang.reflect.Constructor;[Ljava.lang.Object;)Ljava.lang.Object;(ReflectUtils.java:???) at net.sf.cglib.core.ReflectUtils.newInstance(Ljava.lang.Class;[Ljava.lang.Class;[Ljava.lang.Object;)Ljava.lang.Object;(ReflectUtils.java:???) at net.sf.cglib.reflect.FastClass$Generator.firstInstance(Ljava.lang.Class;)Ljava.lang.Object;(FastClass.java:???)Alex

Yup, this is the problem I'm getting as well. If this could be fixed somehow it would be GREAT! Getting a free 2x (almost anyway) performance boost would be nice...

We will be sure to take a look at this. Thanks for the pointer.

Eric
BEA Systems

The problem is that the generated class "$java.lang.Object$$FastClassByCGLIB$$3f697993" is trying to access the method "runFinalizer" in java.lang.Object. This method exists only in JRockit, and is package reachable. The generated class is in package "$java.lang" and can thus not access the "runFinalizer" method in java.lang.Object.

I don't know why CGLIB is trying to access this method. My first thought is that there is a bug with package reachable methods, but I haven't confirmed this.

The problem is detected while JRockit is verifying the generated class. You can work around the problem by running with -Xverify:none in which case I don't get the exception.

I'll keep looking into what the problem is.

Regards,
/Staffan Larsen
JRockit

I can confirm that this is indeed a bug in JRockit. The verication process in some cases throws an IllegalAccessError too early. The exception should be thrown when the method is invoked, not when the class is defined. We are wokring on a fix for this. To work around the problem you can run JRockit with -Xverify:none.

Thanks a lot for reporting the problem!

Regards,
/Staffan Larsen
JRockit

Did you know that LiDO, (JDO 2.0 compliant), works fine on all Java platforms including JRockit without needing to break the integrity of Java.
 


Regards,
Stephane Passignat
Xcalia (www.xcalia.com)

This issue has been identified and fixed in JRockit. The fix is included in our next service pack release of JRockit 5. Customers with a support contract can as always request a hotfix through support.

Henrik Ståhl
Product Manager, JRockit

I really don't understand what the term "freely available for all customers" means: as a customer you paid something to become a customer, so this isn't really free. And what about the people that aren't customers: Aren't they allowed to use this in production? If so, I won't even take a look at it. The times when you could earn something with JVMs are long gone.

Cheers
Michael

Is there any jRockit support/ docs for JNLP, so I can deploy RiA?
.V

There is no license fee for JRockit. It is free for anyone who wants to run any code on it, existing BEA customer or not. We want JRockit to be used as widely as possible.

As a side note, I encourage people to check out the new memory leak detection and code coverage capabilities.

Eric
BEA Systems

How do I start and use the mem leak detector? According to docs for version 1.4.2 (http://e-docs.bea.com/wljrockit/docs142/userguide/memleak.html), there's a tab in the console app, but in the 5.0 console there's no such tab. The docs doesn't tell about it either: http://e-docs.bea.com/wljrockit/docs50/userguide, as far as I can tell.

 Dag.

How do I start and use the mem leak detector?

The memory leak tool isn't availale in the first version of JRockit 5.0. It will be available in 5.0 SP1. Sorry if this caused any confusion.

// Mathias Axelsson, JRockit

I've just been reading the documentation on the site and it looks really impressive, congrats to all involved. Shame the company I work for uses Solaris and SPARC instead :(

Hi,
  I've just installed the JRockit 1.5 JDK SP1 update and I still don't see the memory leak detector. Am I doing something wrong, or is it still not there yet? Thanks,

Chris

Hi,&nbsp;&nbsp;I've just installed the JRockit 1.5 JDK SP1 update and I still don't see the memory leak detector. Am I doing something wrong, or is it still not there yet? Thanks,Chris

Sorry, no, the Memory Leak Detector for 5.0 has not yet been released. It will be. Real soon now...

Regards,
/Staffan

do you have a release date for the memory leak detection tool?

The Memory Leak Detector tool for use with JRockit 5.0 was made available last week -- the link for downloading it is

 http://dev2dev.bea.com/wljrockit/tools.html

  Georges

If Hibernate/Spring/etc do not function on it, it's dead in the water for every project I have worked on for the last 2 years.

If Hibernate/Spring/etc do not function on it, it's dead in the water for every project I have worked on for the last 2 years.

If they "break" the VM to allow an illegal or unsecure operation, then it's dead in the water for every project I've seen for the last two years ;-)

Or maybe instead of cutting our own heads off, we could wait until the CGLIB developers and the jRockit developers have a chance to take a closer look.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

If Hibernate/Spring/etc do not function on it, it's dead in the water for every project I have worked on for the last 2 years.

For the record, Spring does not require CGLIB unless you tell it to proxy a full target class (which can't be achieved through JDK proxies). So Spring should run nicely on JRockit, provided that all AOP proxies are created for interfaces (allowing Spring to use JDK proxies underneath). CGLIB does not even have to be on the classpath in such a scenario.

Of course, the above requires all your proxied application objects to implement business interfaces. But typically you'll proxy at the facade level, where business interfaces are a recommended best practice anyway, so this is not something you'll just do to avoid CGLIB.

Juergen

Eric,

what happened to Thin Threads? Being experimental for years, have they disappeared? I cannot find any mention anymore. I'd be interested to learn

* were they technically too difficult to master (maybe OS intricacies)?
* are native threads "fast enough"?
* has everyone decided not to use many threads, so scalability in that dimension doesn't matter anymore?

Eric,what happened to Thin Threads? Being experimental for years, have they disappeared? I cannot find any mention anymore.

Thin threads were originally introduced to overcome the limitations of the old threading libraries in Linux. However, with NPTL and other improvements in Linux, the benefits of Thin Threads no longer outweighed their own limitations (not being able to effectively deal with JNI code).

We may look into Thin Threads again sometime in the future, but at this point, they don't exist within the current JRockit releases.

Arvind Jain
BEA Systems

I tried running my eclipse on jrockit, and it's a bit
faster than on sun's jvm. Hovewer it uses more memory
for the same heap size (for 64m heap it uses about 30m more
memory than sun's jvm).
I tried to use code cache on my XP, but jrocit crasched
because of access violation ...

The JDK5 jvm from sun seems not stable and crashes quickly with Resin web server, while JDK1.4 functions well.

We'll have a check on JRocket5...

Yes! It's stable! Now we can use JDK5 in programming...

Sun's JDK5 JVM must have a critical BUG.

I downloaded the Win32 version, but I'm unable to debug in Eclipse 3.1M4. Works fine with Sun's 5.0 JVM.

Can you include some more details on what you are trying to do and how it doesn't work? I've been using JRockit 5.0 and Eclipse 3.1m4 without problems, and if there is some problem I'd like to understand it.

If you wish, you can move the discussion to the JRockit forum at BEA: http://forums.bea.com/bea/category.jspa?categoryID=2010

Thanks,
/Staffan

Just wanted to notify you all that SP1 was made available as of today.

/Charlie Helin, JRockit