New Version of JRockit 5.0 available for download

Discussions

News: New Version of JRockit 5.0 available for download

  1. BEA has made an updated version of JRockit 5.0 available for download at http://commerce.bea.com/products/weblogicjrockit/5.0/jr_50.jsp

    This update bundles J2SE 5.0 Update 2 and contains improvements to runtime performance and startup time as well as a number of fixes for known problems.

    Supported downloads include:
    • BEA JRockit 5.0 JDK with SP1 for Microsoft Windows (Xeon - 32 bit)
    • BEA JRockit 5.0 JDK with SP1 for Microsoft Windows (Itanium - 64 bit)
    • BEA JRockit 5.0 JDK with SP1 for Linux (Xeon - 32 bit)
    • BEA JRockit 5.0 JDK with SP1 for Linux (Xeon - 64 bit)
    • BEA JRockit 5.0 JDK with SP1 for Linux (Itanium - 64 bit)
    JRockit is freely available for development and production use for any Java application.

    Threaded Messages (14)

  2. CGLIB issues fixed?[ Go to top ]

    Hi,
    I wonder if this new release fixes the compatibility issues with CGLIB reported before.

    Thanks // Torben

    stacktrace.se
  3. CGLIB issues fixed?[ Go to top ]

    As far as I know, all issues reported here and through the JRockit user forums have been fixed. See the release notes for details, and let us know if there still are issues.

    Download link here.

    Henrik Ståhl
    JRockit Product Manager
  4. BEA doesn't get it.[ Go to top ]

    BEA JRockit 5.0 JDK with SP1 for Linux (Xeon - 64 bit)

    What the hell is Xeon - 64 bit.

    They support the Itanium (since a long time) that has sold 3 machines I think. They did not have support for Opteron for 2 years and now their PR tells us they support Xeon - 64 bit and I still don't see the O word anywhere.

    Well, I hope they get tons of money from Intel, because I don't think they will get much from the growing number of datacenters based on Opteron blades.
  5. BEA does get it[ Go to top ]

    We are working on revising our supported platform pages to make them more clear on this point. In the meantime:

    Xeon is Intel's line of high-end server and workstation processors (very similar to Pentium).

    The "Intel Xeon EM64T" version is supported on compatible chips, including AMD Opteron.

    Btw, what would you like to call this architecture? EM64T and AMD64 are both vendor-dependent. Other options we seen are "x64" (Windows and Solaris) and x86-64.
  6. other 32 bit processors?[ Go to top ]

    Would JRockit run safely on other 32bit processors than Xeon?
  7. other 32 bit processors?[ Go to top ]

    Leos,

    If you mean, would it run on other x86 processors, the anwser is yes. As long as it is a Intel Pentium II or higher (and compatible)

    Charlie Helin, JRockit
  8. They have not yet fixed a bug where the largest possible array size is one less than 256*1024*1024. Even with -Xmx512m, the following will give an error...

    [code]
    public class MemTest
    {
        public static void main(String[] arguments)
        throws Throwable
        {
            byte[] bytes = new byte[256 * 1024 * 1024];
        }
    }
    [/code]

    ...though one less than this will run fine.
  9. Alex,

    You posted a question regarding this issue in our newsgroup April 15, which unfortunately was too late to get it into our April 29 release. As we replied there, it will be fixed in an upcoming service pack. Thanks, and please let us know if you run into something else!
  10. Comparison[ Go to top ]

    Is somewhere any comparison of available JVM's? Sun JVM, IBM, HP, BEA JRockit... ? In which parmeters is JRockit better than Sun - for example?
  11. Comparison[ Go to top ]

    Is somewhere any comparison of available JVM's? Sun JVM, IBM, HP, BEA JRockit... ? In which parmeters is JRockit better than Sun - for example?

    Something is here: http://www.shudo.net/jit/perf/

    Sometimes one is faster, sometimes one is slower. No big differences. Depends on tuning and your benchmark ...
  12. Comparison[ Go to top ]

    That's one. However, many of the benchmarks on that page are skewed towards scientific computing (scimark, linpack, Erathostene's Sieve, parts of SPECjvm98), which is probably not the most common use of Java. The last (specjvm98) is an old - but admittedly valid - client side benchmark. We know that JRockit does not excel at floating point, and it is one area we are looking at for future optimizations.

    Other public benchmarks, with more of a server-side focus are SPECjbb and SPECjAPP. The former puts most emphasis on memory management. There is a recent result published on JRockit here, as well as a full list of results here. When we run head-to-head comparisons vs Sun Hotspot, we see that JRockit generally outperforms Hotspot by a significant amount on an otherwise identical setup. Of course, I encourage those of you who have access to this benchmark to verify this yourselves.

    SPECjAPP is designed to benchmark an application server, so it does not directly measure the JVM. If you have the benchmark, you can however run identical setups and switch the JVM only. I wouldn't be surprised if you got good results with JRockit.

    Common reports from customers who have switched from Sun Hotspot to JRockit is everything from no change to twice as fast. This is generally on larger server applciations, where JRockit self-tuning and runtime optimization is given time adapt itself to the application.

    At the end of the day, the only benchmark really worth its salt is your own application. Try out JRockit with your app - it's free to use - and let us know the results!

    Oh, and if you have a benchmark that runs poorly with JRockit, post it to our newsgroup. Chances are we will fix your issue, such as in this example.
  13. Vectorization[ Go to top ]

    Are there any plans to introduce auto-vectorization in JRockit? Utilizing SSE to perform parallell computations could mean a huge performance boost for some applications. GCC 4.0 and the Intel C++ compiler perform some auto-vectorization of loops, although I'm not sure how well it works in practice.
  14. Vectorization[ Go to top ]

    Are there any plans to introduce auto-vectorization in JRockit? Utilizing SSE to perform parallell computations could mean a huge performance boost for some applications. GCC 4.0 and the Intel C++ compiler perform some auto-vectorization of loops, although I'm not sure how well it works in practice.

    Auto-vectorization (using SSE*) is not (to my knowledge) scheduled in any plans. I guess that comes from server side applications (afaik) not being as "math intense" to get big improvements from auto-vectorization. It might be something for the future though.

    Personally, I think it would be much easier if there was a standardized vectorization package (or additions to the language, whatever). The JVM could then choose to implement whatever parts of that library using hardware concious intrinsics. Not as a replacement for auto-vectorization but as a complement to it. Strange that a JSR for that hasn't come along yet (or has it?).

    olof lindholm, bea systems
  15. To summarize, new in this update:

    J2SE 5.0 Update 2

    Better runtime performance
    Improved performance of optimized code
    Support for large memory pages on x86 (-XXlargepages)

    This yielded a 15% performance improvement from the previous release on SPECjbb2000, see results here.

    Shorter startup times
    Mainly due to faster code generation

    Enhanced diagnostics
    More on this shortly

    Henrik Ståhl, JRockit