Why JDK6 again ?

Again a comparison and reason why JDK6. Weeks back one of our team member gave a presentation on JVM performance improvement in Mustang. I have just collected a useful point here and try to compare with older JDK version. Here is the code:

import java.util.\*;

public class RuntimePerformanceGC {
 
    public static void main(String[] args) {
        RuntimePerformanceGC ob = new RuntimePerformanceGC();
        Vector v = new Vector();
        java.util.Date now = new java.util.Date(); 
        long t1 = now.getTime();                   
        ob.addItems(v);
        java.util.Date now1 = new java.util.Date();
        System.out.println(now1.getTime()-t1);
    }
    public void addItems(Vector v) {
        for(int i =0;i<500000;i++)
        v.add("Item" + i);
    }
}
 

And the output in ms is:

JDK1.4.2: 984

JDK 6: 578

You can see a massive difference. 37 percent improvement in time. Why ? Here goes :

This is because of Runtime Performance Optimization. The new lock coarsening optimization technique implemented in hotspot eliminates the unlock and relock operations when a lock is released and then reacquired with no meaningful work done in between those operations. And this is what happening in our example. Since, Vector do thread safe operation, it takes the lock for add, release the lock and then takes it again. 

So, I just tried to give one more reason why use JDK6 ;-). This is off course not the only reason for big improvement, I will try to cover some more in upcoming blogs :-)


Comments:

Interesting read. Thanks. I look forward to further posts on "Why JDK 6".

Here's something that I noticed today: The latest version of Tomcat at the time of writing has a startup time of 970ms on JDK 1.5.3 vs 730 ms on JDK 1.6

Posted by Sriram Narayanan on June 28, 2008 at 05:10 PM IST #

Sure. See, JDK6 rocks :)

Posted by Vaibhav on June 28, 2008 at 05:17 PM IST #

Jeroen Borgers has written 2 nice articles about thread related performance optimalisations in Java 6:

http://www.infoq.com/articles/java-threading-optimizations
http://www.infoq.com/articles/java-threading-optimizations-p2

Maybe you could have a look at them.

Posted by Peter Veentjer on June 30, 2008 at 05:56 AM IST #

[ You can see a massive difference. 37 percent improvement in time. Why ? Here goes ]

Beware of the microbenchmark: http://www.ibm.com/developerworks/java/library/j-jtp02225.html

In particular "No warmup was performed, and it made no account for the time taken by JIT execution."

Posted by BlogReader on June 30, 2008 at 12:14 PM IST #

@BlogReader :

Last line: This performance improvement is not only because of this. Even this improvement is not even 10 percent of the original improvement. But but, it makes a difference and it make a big difference.

By the way, thanks for the article, article looks good !

Posted by Vaibhav on June 30, 2008 at 12:25 PM IST #

Thanks Peter Veentjer. Those articles are good.

Posted by Vaibhav on June 30, 2008 at 12:27 PM IST #

This is a side point but

long start = System.currentTimeMillis()

does the same thing as

java.util.Date now = new java.util.Date();
long t1 = now.getTime();

only shorter and much faster. If you want slower, new Calender().getTime().getTime() is a good one.

Of course if you were using Java 5 for comparison, you would use

long start = System.nanoTime();

Which is many, many times more accurate.

Posted by Peter Lawrey on July 02, 2008 at 04:19 AM IST #

yes Peter, thats true. Actually I am using nanoTime() but comparing with 1.4.2 put me in mess up. Not compared with 1.5 because 1.5 is not on my machine :D

Posted by Vaibhav Choudhary on July 02, 2008 at 04:52 AM IST #

Post a Comment:
Comments are closed for this entry.
About

Hi, I am Vaibhav Choudhary working in Sun. This blog is all about simple concept of Java and JavaFX.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today