JRockit optimizations

Performance Tuning
#1

I’ve been reading JavaOne TS1904 session about the internals of BEA JRockit JVM (http://javaoneonline.mentorware.net/servlet/mware.servlets.StudentServlet?mt=1102701269329&mwaction=showDescr&class_id=28143&fromtopic=By%20Topic&subsysid=2000&topic=technical&avail_frames=true). These JVM optimizations should have inspired Sun engineers and been included in Sun JVM a long time ago:

  • No distinction between client/server mode. The JVM starts as client an the code is progressively compiled/optimized to server bytecode (adaptatiove optimization).
  • Compilation result saved for later runs and speedy restart.
  • Very agressive optimizations.
  • On stack object allocations.
  • many more…

Have some of you tested this JVM? What do you think of it?

#2

Here are some benchmarks:

http://www.shudo.net/jit/perf/
http://www.excelsior-usa.com/jetbench.html

JRockit looks good. But that’s no surprise, it’s developed in Sweden ;D A new version of JRockit with 1.5 support will be released very soon.

#3

I am particularly interested in the JNI call performance. It DOUBLES that off client 1.4.2_04!

However, Reflection is just slightly behind.

Heck, in the JFCMark 10/100 its up there with Jet!

Im impressed…

#4

Well, JRockit is impressive when it comes down to “real” performance - but startup time isn’t soo impressive compared to client-jvm.

However JRockit’s target is mostly server-mode, however especeally some features make it more and more interresting for client-side use - but as far as I know it is NOT free and costs “real” money. You can download and try it, but as far as I know you are not allowed to redistribute it :frowning:

However its great and as you said before it would be cool if Sun would not only always tell us how great hotsopt is, but just make it better with some “foreign” ideas.

lg Clemens

#5

[quote]Well, JRockit is impressive when it comes down to “real” performance - but startup time isn’t soo impressive compared to client-jvm.
[/quote]
but, "Compilation result saved for later runs and speedy restart. ", so maybe its ownly sluggish the first time? I think people could live with that – many applications are quite slow on their first run.

Will.

#6

A little bit crap for downloadable games though. You get 1 minute to make a first impression :frowning:

Cas :slight_smile:

#7

You obviously haven’t played “Breed” then :slight_smile:

4 - 6 minutes EVERY startup to tell you “loading”! And thats on pretty decent HW.

DP

#8

[quote]Here are some benchmarks:

http://www.shudo.net/jit/perf/
http://www.excelsior-usa.com/jetbench.html

JRockit looks good. But that’s no surprise, it’s developed in Sweden ;D A new version of JRockit with 1.5 support will be released very soon.
[/quote]
Looking through some of those benchmarks, one thing that I noticed is that Sun’s JVMs seem to do better on Opteron (compared to the competition) than on Xeon. I’ve noticed this myself - last year I was doing some C vs Java stuff on Opterons and Xeons, with Sun’s JVM, and on Opteron it was beating the C code all the time - even when compiled with Intel’s C compiler! (on Linux)

#9

Actually I think the .NET runtime does this as well.

#10

[quote]Looking through some of those benchmarks, one thing that I noticed is that Sun’s JVMs seem to do better on Opteron (compared to the competition) than on Xeon.
[/quote]
I wonder if that is mostly related to the memory architecture on the Opterons? I haven’t compared Java vs C on an Opteron, but I’ve run very compute-intensive C++ code on both a P4 and Athlon64 of identical cost. I was blown away by the complete thrashing I witnessed - the Athlon64 ran the computations 3x faster than the P4. My guess is that the P4 gets trounced because it spends most of its time floundering on cache misses. (Traversing a graph with nodes semi-randomly spread throughout memory isn’t particularly amenable to caching).

So, perhaps Sun’s VM is doing some stuff that isn’t particularly cache-friendly?

God bless,
-Toby Reyelts

#11

Its possible, but we haven’t spent alot of time lately working on cache issues. Try this interesting little test, find a nice large application and run the VM from different sized directories. For example:

c:\java\bin\java -server myApp

c:\program files\java\jdk1.5\bin\java -server myApp

You’ll see a noticeable performance difference.

#12

[quote]Try this interesting little test, find a nice large application and run the VM from different sized directories. For example:

c:\java\bin\java -server myApp

c:\program files\java\jdk1.5\bin\java -server myApp

You’ll see a noticeable performance difference.
[/quote]
I don’t understand what you’re saying. Two identical JVMs with one installed at a longer path and you’re saying the one installed in the shorter named path will run an application faster? Do you mean “load” an application faster or actually spend less time in overall execution? And what do you mean by “large app”? - Disk space (class files), heap space, or cpu time?

It sounds like you’re yanking my chain.

God bless,
-Toby Reyelts

#13

JRockit 5.0 has been released and is available at:

http://commerce.bea.com/products/weblogicjrockit/5.0/jr_50.jsp

Good news for us who use Java 5. Doesn’t seem to be many changes to the JVM in this version except for a new GC algorithm. Time to do some benchmarking… :slight_smile:

#14

JRockit (in my experience) is insanely easy to crash. Especially if you want to run a profiler or debugger against it. Especially especially if you use the code cache.

#15

Well, on my systems it runs server-code under heavy load and does slightly better than hotspot-server.
It just fells more “robut” with its performance, I cannot explain it better.

Well, I never attached a profiler or a debugger on it, but well, debug in sun-jvm and run it on JRockIt. Btw. codecache ist still experimental - they do not even support it with weblogic :wink:

However they show inovations - I am getting tired of SUN telling me the last 5y that their hotspot-jvm is so great and so wonderful but its outperformed by IBM, Bea and .NET (which can be compared to Java).
They do not have a code-cache nore a more-depth optimizing compiler and they claim their startup-times have decreased since 1.2.2 by 25% each release but 1.5 does start up slower than 1.2.2 - so something went wrong?

AND: SUNs license is disgusting!!! - Have you ever read it - its just crap!

lg Clemens

#16

I carefully read it, ignored it, and included it in my distributions :slight_smile:

Cas :slight_smile:

#17

Hi,

Noticed on Swing chat transcript (http://java.sun.com/developer/community/chat/JavaLive/2005/jl0215.html):

[i]markyland: Are there any plans to allow Swing applications to be compiled natively?

Scott Violet: The closest thing I can say we’re looking into is persisting compiled code between runs of the JVM. For example, each time you run your application we end up compiling a lot of the same methods; if this were cached it could conceivably speed things up. Whether or not something like this makes it in depends upon the results we get.[/i]

At least Sun discovers that keeping compilation results or profiling can benefit to multiple runs (or has IBM a patent for using this technique in REXX 20 years ago?)… Next time (in 10 or 15 years?), perhaps they’ll discover stack allocation for small short lived objects with escape analysis…

#18

They still do nnot have stack-allocation in server-jvm??

I really do not understand why they claim to be so innovative…

#19

They appear to be totally mismanaged from a very high level.

Cas :slight_smile:

#20

[quote]They still do nnot have stack-allocation in server-jvm??

I really do not understand why they claim to be so innovative…
[/quote]
Feel free to write your own JVM with all the features that Hotspot provides.