Java 7 What`s New, Performance Benchmark 1.5 1.6 1.7

Java is one of the language which has overhauled it’s underneath technology ground-up. Even though, the basic concept of running inside JVM holds good, the way JVM handles Objects, Memory management has completely been revamped.

A lot  changed over 1.4 to 1.5. There were critical compile-time improvements, Runtime smartness and with Java 6 more performance optimizations; Java 7 – the modularity.

Let’s start discussing each aspect of Java 7 which makes it go Loud –

  • Modularization – JSR 294 or Project Jigsaw
  • JVM Support for dynamic languages
  • More New I/O APIs which are nearly finished, includes true asynchronous I/O  and finally a real file system API – JSR 203
  • The native language support for XML. (probable)
  • Safe rethrow – Allows a broad catch clause, with the compiler being smarter on what you’re allowed to rethrow based on what is thrown from the try block. (I had not seen this before but it looks nice)
  • Null dereference expressions – Null checks with ‘?’ syntax similar to Groovy… lettign developers avoid a nest of null checks.
  • Better type inference – Example around generics instantiations, but it was not clear how far the inference would be taken (the more the better in my opinion).
  • Multi-catch – Allows a comma separated list of disjunctive exception types in catch clause.
  • JSR 296 – Swing application framework – It still needs to be easier to create Swing apps.
  • Update: As per Sun Blogs

After much discussion it’s become clear that theSwing Application Framework API as it is today hasn’t reached consensus and we feel still needs further design work done.

Since the SAF API was committed to milestone 5 of JDK7 and that time is already here, this date is now impossible, and we need to decommit SAF from any specific JDK 7 milestone.

The “Small” Sun changes are:

  • Upgrade class loader architecture – Work started in Java 5 and continues to evolve. There are some deadlock issues today in classloader delegation that will be addressed.
  • XRender pipeline for Java 2D – This was an Open JDK Integrators Challenge project,and is an analog to the OpenGL pipeline but much more portable across x11.
  • Swing Updates – JXLayer, DatePicker, CSS styling (maybe) that Ethan Nicholaus (sp?) has been working on
  • JavaFX

Update: Few new Small changes of  “Project coin” are available here.

The “Fast” changes from Sun (This refers to performance improvements):
Hotspot run-time compiler enhancements

  • A couple of concurrency (JSR 166) tweaks (Better support for Multicore)
  • G1 Garbage collector- Leads to much smaller pause times and hopes to replace CMS (Concurrent mark sweep) GC
  • Compressed pointer 64 bit VM
  • MVM-lite – Multiple Virtual Machines will help run isolated applications and allow a kill -9 on a Java application. Mark said it is not clear what problem would be solved, and original project was extremely ambitious, but desire to drag apps out of browser plugin presents a good usage and need for MVM. (This could be moved to a later release)

The Theory and Practical

As far as what changes you’ll see in your day-to-day work, my guess is that the major impact will be stuff like JSR 203 which overhauls the file system API. If JSR 310 is included, then it would also have a major impact on how you interact with any aspect of the date and time APIs. Many of the other JSRs will only impact you if you happen to already do something in that particular area (JMX – JSR 255, concurrency – JSR 166, etc).

The biggest thing most people will notice may be performance. This is my favorite. And that is exactly what I thought about writing, and it expanded the scope to features aswell. As usual, each JDK brings a whole new set of performance optimizations. We’ve already seen some very encouraging results in String performance, array performance, and a new concurrent garbage collector (G1). I suspect many people will find that their existing code will work and run noticeably faster than it did in the past.

Performance

I saw this one about the new features in Java 7:

http://www.ibm.com/developerworks/java/library/j-jtp03048.html

They use MergeSort as an example of how to exploit multiple CPUs for sorting. Java 7 has the nice feature, that it can now decide at runtime, how many threads should be used to solve a particular problem (see the coInvoke part).

However, there is this tricky constant, SEQUENTIAL_THRESHOLD, which is used to decide whether to enforce sequential processing or not. How do you set this value? Well, you set it at design time, even though the example was meant to show how Java adapts at runtime…

The next thing is that the whole array is passed as parameter. No matter what programming language you use, this is a bad design. If Java doesn’t copy the memory, you may have 2 CPUs looking at the same RAM area. If Java has a runtime optimization that detects that 2 CPUs are looking at the same area, and decides to copy the data, it will copy too much data…

I’m not sure this example would perform better on a 4-CPU machine than on a single-CPU machine with the same CPUs…

The basic problem in all this is, that it is extremely hard to find real world examples of parallelization of algorithms that can be optimized to any kind of parallel hardware. Good multi-threading must be done on a functionality level, not on the algorithm level.

Also, every time we add multi-threading to code, we make it more complex. In other words, it comes at a cost. I predict that some of the future performance gains don’t come from making algorithms more threaded, but from changing data structures, reducing memory footprint and simple optimizations. As the price of more performance increases, efforts will be spent where most speed can be gained at the lowest price.

Benchmarking JDK 7

As per Sun, The JDK 7 delivers quite a speed boost over JDK 6 array accesses. For us, this is huge. It’s like another year and a half of Moore’s law for free. Only in software. And you don’t even have to write multi-threaded code.

It’s basically a stress test that I used for ArrayLists, HashMaps, gets, array sets, and simple multiply-add-subtract, arithmetic, and concurrency APIs, Threads.

I installed the following beta release of JDK 7:

> java -version
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b66)
Java HotSpot(TM) Client VM (build 16.0-b06, mixed mode, sharing)

Java has always suffered relative to C/C++ in  matrix multiplication because Java does range checks on every array access (set or get). With some clever static and run-time analysis, we are able to eliminate most of the array bounds checks. They show on matrix benchmarks that this one improvement doubles the speed of the LU matrix factorization benchmark in the U.S. National Institute of Standards (NIST) benchmark suite SciMark 2, which like our clustering algorithm, is basically just a stress test for array access and arithmetic.

I’m pretty excited about the new fork-join concurrency, too, as it’s just what we’ll need to parallelize the inner loops without too much work for us or the operating system.

I decided to take my on Test-check for performance for Java 7 and then compare it with 5, 6.

My tests have been on a Dell D630 Notebook running Windows 7 RTM (32 bit) with an Intel Core 2 CPU (2.4GHz), and 3GB of RAM.

Here are the Benchmark Tests –

Test 1. Add 5 Million String values (each calculated with some complex Math arithmetic)

Test 2. ArrayList <String> with 5 Million insertions (with values from Test1). Insertions are conditional and have additional computation before adding to array.

Test 3. HashMap <String, Integer> with 5 million keys, values. Each key, value pair is being calculated via concurrent thread. (This tread tests both Arithmetic and concurrency capabilities)

Test 4. Printing 5 million items of ArrayList <String> to number of Files (1000) and Reading back again. (Tests multicore concurrency to the edge) My CPU, HDD, RAM all went to Max.

All of these tests were very memory intensive. Heap size varied between 1 – 2 GB during tests, due to large no. of objects. CPU Utilization was sometimes 50% (1 core’s max) and most of the time >70% and in Test3, Test4; CPU touched 100% most of the times.

The Result is mind blowing!

And the Result The Winner is … Java 7

Java 5 <=== 18% faster=== < Java 6 < ===46% faster===< Java 7

Note – This was totally based upon my tests, doesn’t necessarily means it’s for overall Java. The results may vary for different kinds of computations.

Alright, When is Java 7 coming ? 🙂

GD Star Rating
loading...
GD Star Rating
loading...
Java 7 What`s New, Performance Benchmark 1.5 1.6 1.7, 7.8 out of 10 based on 6 ratings

23 thoughts on “Java 7 What`s New, Performance Benchmark 1.5 1.6 1.7”

  1. – multicatch is not there
    – null dereferences (elvis operator) are not there
    – first time I hear about language support for xml
    – from where you got information about mvm inclusion ? it would be great, but I seriously doubt it

    I think that single biggest change in JDK 7 will be invokedynamic together with all the infrastructure for supporting more dynamic languages – it will have major impact on their execution speed.

    GD Star Rating
    loading...
    GD Star Rating
    loading...
    Reply
  2. > The “Small” Sun changes are:
    > The “Fast” changes from Sun

    From Sun? Only from Sun? And where is IBM? Where is Oracle, Redhat, Intel, HP, Nokia and the rest?

    Hopefully Oracle will make Java a truly open standard controlled by an independent foundation. So all (!!!!) companies involved in Java-technology can (and hopefully) will contribute to ameliorate the JVM.

    It’s a shame that the whole processus of JRE/JVM-development was closely controlled and owned by Sun-Microsystems during the last 13 years. I hate that “Sun-only-Java” that you just described. We are not the same like that totalitarian regime named Microsoft.

    GD Star Rating
    loading...
    GD Star Rating
    loading...
    Reply
  3. Hi,

    What version of JDK6 did you use? You will notice that JDK6u18 early access release has a HotSpot that is almost the same as the one from the latest JDK7 snapshot (HS16b08). Similarly, JDK6u16 has a HotSpot that is almost the same as the one in a JDK7 snapshot from some months back.

    Basically, Sun has been including a new HotSpot in JDK6 every few releases (JDK6u4, JDK6u10, JDK6u14 and now JDK6u18, although the latter is not yet final), so one can get access to HotSpot improvements without waiting for JDK7.

    Best,
    Ismael

    GD Star Rating
    loading...
    GD Star Rating
    loading...
    Reply
  4. If you want high peek performance you shouldn’t use the hotspot client compiler, but the hotspot server compiler (use the “-server” argument). This compiler performs far more aggressive optimizations than the client compiler but has a slower warm-up time.

    GD Star Rating
    loading...
    GD Star Rating
    loading...
    Reply
        • java can theoretically be faster than c++ because it can apply performance tweaks DURING RUNTIME. e.g. c++ code doesn't magically inline functions for you if you're calling them a lot, java does.

          GD Star Rating
          loading...
          GD Star Rating
          loading...
          Reply
      • “It might approach their speed but never will be faster since it itself is written in c/c++”

        Actually, no. You are confusing the runtime with the JITted native code generated from Java class files. The native code is generated by a module (compiler) written in C++, but the implementation language of the compiler does not affect the performance of the generated code, only the speed of generating this code.

        GD Star Rating
        loading...
        GD Star Rating
        loading...
        Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.