Caveats to watch for in transition from Sun JVM to JRockit?

Question

We are thinking of transitioning a large product from relying on Sun's JVM to JRockit. I'm not naive enough to believe that this is going to be a smooth transition (though I'd love to be wrong).

What issues should we watch out for or focus our regression testing on?

Kingston

The main problem with JRockit is that its instability is hard to reproduce. Simple regression testing will not reveal its horrors. It is only under high production load that sporadic hung threads will occur. Why on earth would you switch from Sun to JRockit? – Merrymaking

After a few jumps from searching for JRockit I ended up here: shudo.net/jit/perf Where there are some awesome performance tests showing Java server faster than C compiled with GCC (Visual C++ is still faster in most cases.) +1 awesome... But I'm afraid it doesn't make JRockit look very well.. – Papp

This sounds like an attempt to pull more performance out of an app by throwing some money and technology at it. In your place (easy for me to say!) I'd try to educate your management to understand that the alleged gains come at the price of instability, which also has a cost. It is very often possible to gain more performance with less risk through the proven practices of profiling, improving algorithms and finding opportunities for raising concurrency. – Dvandva

Let's just say that it's not my call to make or affect, unfortunately. I prefer tried-and-tested tools like the standard Sun stuff. . – Kingston

Answer 1

Well, of course you have unit tests right? :-)

I have used JRockit somewhat just for "fun" and have never had issues. From what I can see it is used in a number of apps of a wide variety so it should probably just work. It seems that it has also passed the JCK (the compatibility tests from Sun), so it should be smooth.

Areas that I would think of for breaking would be:

• garbage collector
• native code (JNI)
• file system handling, threading, etc... (unless they use the Sun library code)

The file system, threading, etc... are all the parts of the VM that integrate with the underlying OS. If they use the Sun code then less chance of issues.

I would bet that the transition does go smoothly.

Inexpressible

That's precisely it: they don't use Sun's native code for socket I/O and threading. They use their own... because it's so much faster (not!). Unfortunately this negligible speed enhancement comes with major instability. I hope when Oracle completes the Sun deal they will exterminate JRockit. – Merrymaking

@sylvarking: Any links to instability horror stories would be extremely useful :) – Kingston

Sorry, my opinion is based on personal, anecdotal experience with a large application for a customer that wouldn't appreciate my sharing. – Merrymaking

Answer 2

As I always say: There is only one way to find out: do it!

The transition should take about what... 30 minutes ( you just install JRockit and change the path somewhere right? )

You should be ok.

I had problems in the past with JDBC which were extremely strange ( because the problematic code was in the PreparedStatement reference that as we all know is just an interface. The underlaying driver was exactly the same.) I've got this strange error messages all over the place about the insert intostatement.

To be honest there was another variable here, I was migrating from Java 1.2.2 to Java(JRockit) 1.4 and yet, I think I shouldn't have had all those problems.

But again, it should be fast enough to find out. In my case I saw I had these problems in < 5 minutes and since that was just an experiment ( I attended to this BEA developers day when they talked about the great features JRockit had ) I just dismissed it.

Chromate