Tuesday Jul 08, 2008

Netbeans Configuration - Optimal ?

Oh today Angad was doing his project on Netbeans and suddenly start asking about GC Algo's. I asked "What happened" and it seems he was tuning the file "netbeans.conf" in netbeans\\etc. I have seen the same file on my computer. I was little surprised!

Maybe I don't know in detail because this all happened some 2 hrs back. But what we observe netbeans is not tuning the parameter or writing the file (netbeans.conf) according to system configuration/properties. Correct me if I am wrong, Netbeans write the same netbeans.conf file if I am working on a duo core processor or if I am working on a P2 machine. If yes, then I definitely want to know why? I guess Java provide enough API to know about no. of processor, RAM, disk, OS information and many more. Why not this file is best written according to machine configuration. Certainly a safe playing value in which we take care of the fact that netbeans or any process will not eat too much of RAM/Processor. This file should be written at the time of installation by reading the machine configuration.

Angad has given one more good suggestion, at the time of installation we can ask about the settings user want(current one or optimal tuning). Should be some reason of not doing this, but love to know why ?(No doubt, the tuning is written in best universal way, but why not specific)

By the way, got the tuning page of Netbeans : http://performance.netbeans.org/howto/jvmswitches/index.html.

Also, saw a plugin which takes input for command line setting(start up): http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=6829

Saturday Jun 28, 2008

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 :-)


Sunday Apr 27, 2008

Atomic Operations in Java

Knowing atomic operation is very important when we are writing thread operation in Java. Covering atomic operation inside synchronized keyword is just a overhead which we discussed sometime back in one post. Now what all comes under atomic operation:

1. a = a + 1 - certainly not. Because this operation can use a local variable or a register to store the information before assigning it back to a. This operation is more or less like:

temp = a+1;
a = temp;

2. a = b; Is this a atomic operation ? It depends ! Java Specification says that assignment to variables smaller than or equal to 32 bits is an atomic operation, which excludes variables of types double and long (both are 64 bits). So, the operation is atomic or not completely depends on type of a and b. Now, reason behind such a specification is very clear, any operation more than 32 bit should need a extra storage(basically register) for a 32 bit processor. But here Java Spec is not speaking about any processor dependency. Now, I am surprised how VM will handle atomicity if ran on 16 bit processor. I don't know but I guess we can run JVM on 16 bit processor. Is it handles atomicity internally ? How about 64 bit processor. Even double and long operation should be atomic.

I am confused :-(

About

Hi, I am Vaibhav Choudhary working in Oracle with JDK team. This blog is all about simple concept of Java, JVM and JavaFX.

Search

Archives
« July 2015
SunMonTueWedThuFriSat
   
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
31
 
       
Today