Scenario:
Project A, B and C is dependent on say X.jar. I am updating the X.jar where those files are only related to Project A. But eclipse builds all the three projects,if the jar gets updated.
Problem: Eclipse has all the dependencies graph(I believe) and why it is behaving like this?
If its build only project A then lot of time will be saved.
Worst case scenario will be when JDK changes (I am seeing this also as a JAR changes),so only the files which are compatiable with the latest versions and it dependencies shuld be built.
It should try for the incremental build . Any thoughts guys......
Friday, November 30, 2007
Tuesday, August 7, 2007
Escape Analysis in Mustang (Java SE 6)
Escape analysis
The Java language does not offer any way to explicitly allocate an object on the stack, but this fact doesn't prevent JVMs from still using stack allocation where appropriate. JVMs can use a technique called escape analysis, by which they can tell that certain objects remain confined to a single thread for their entire lifetime, and that lifetime is bounded by the lifetime of a given stack frame. Such objects can be safely allocated on the stack instead of the heap. Even better, for small objects, the JVM can optimize away the allocation entirely and simply hoist the object's fields into registers.
Escape analysis in Mustang
This analysis is an optimization that has been talked about for a long time, and it is finally here -- the current builds of Mustang can do escape analysis and convert heap allocation to stack allocation (or no allocation) where appropriate. The use of escape analysis to eliminate some allocations results in even faster average allocation times, reduced memory footprint, and fewer cache misses. Further, optimizing away some allocations reduces pressure on the garbage collector and allows collection to run less often. Escape analysis can find opportunities for stack allocation even where it might not be practical to do so in the source code, even if the language provided the option, because whether a particular allocation gets optimized away is determined based on how the result of an object-returning method is actually used in a particular code path.
Conclusion
JVMs are surprisingly good at figuring out things that we used to assume only the developer could know. By letting the JVM choose between stack allocation and heap allocation on a case-by-case basis, we can get the performance benefits of stack allocation without making the programmer agonize over whether to allocate on the stack or on the heap.
The Java language does not offer any way to explicitly allocate an object on the stack, but this fact doesn't prevent JVMs from still using stack allocation where appropriate. JVMs can use a technique called escape analysis, by which they can tell that certain objects remain confined to a single thread for their entire lifetime, and that lifetime is bounded by the lifetime of a given stack frame. Such objects can be safely allocated on the stack instead of the heap. Even better, for small objects, the JVM can optimize away the allocation entirely and simply hoist the object's fields into registers.
Escape analysis in Mustang
This analysis is an optimization that has been talked about for a long time, and it is finally here -- the current builds of Mustang can do escape analysis and convert heap allocation to stack allocation (or no allocation) where appropriate. The use of escape analysis to eliminate some allocations results in even faster average allocation times, reduced memory footprint, and fewer cache misses. Further, optimizing away some allocations reduces pressure on the garbage collector and allows collection to run less often. Escape analysis can find opportunities for stack allocation even where it might not be practical to do so in the source code, even if the language provided the option, because whether a particular allocation gets optimized away is determined based on how the result of an object-returning method is actually used in a particular code path.
Conclusion
JVMs are surprisingly good at figuring out things that we used to assume only the developer could know. By letting the JVM choose between stack allocation and heap allocation on a case-by-case basis, we can get the performance benefits of stack allocation without making the programmer agonize over whether to allocate on the stack or on the heap.
Thursday, April 26, 2007
is all string manipulations requires synchronization?
The Java language specification assures us that strings are immutable, so most operations on a string destroy the original object and create a new one. But in reality the compiler can optimize the operation and reuse the same memory as the original string. For instance we have a string ‘String stringSample = "Saravanan";’ stored in memory at memory location m1. The compiler will store this String in memory as origin location = m1 and offset = 12.
Now when an operation ‘stringSample = stringSample.substring(4);’ is done, stringSample will contain "vanan".
As per the Java specification we would assume that stringSample will be moved to a new location m2 and the old memory location is left for the garbage collector, but compilers can reuse the same memory location and update the offsets. So the new string after the sub string operation would read as origin location = m1+4 and offset = 8. This does not break the Java specification, as the old reference is lost and a new reference is created with a new origin location and a new offset. The problem is when two threads try to access this string at the same time; the second thread might get the wrong starting location.
Now when an operation ‘stringSample = stringSample.substring(4);’ is done, stringSample will contain "vanan".
As per the Java specification we would assume that stringSample will be moved to a new location m2 and the old memory location is left for the garbage collector, but compilers can reuse the same memory location and update the offsets. So the new string after the sub string operation would read as origin location = m1+4 and offset = 8. This does not break the Java specification, as the old reference is lost and a new reference is created with a new origin location and a new offset. The problem is when two threads try to access this string at the same time; the second thread might get the wrong starting location.
Tuesday, April 10, 2007
is this a java bug?
class ArrayTest{
public static void main(String arg[]) {
int a[]=new int[0];
a[0]=5;
}
}
It will compile fine,when I run this code,its saying ArrayIndexOutOfBoundException....
As we know array declaration should have one integer value,even if I give -1 also it will compile. But in runtime it is saying NegativeIndex or ArrayIndexOutOfBound for -1 or 0 respectivley.
Why it is doing like this? While doing compiling itself why don't the compiler has do that? I accept for the variable initialization since it has clue for the variable in the compilation time,but for straight forward initialization like above should caught by the compiler... is my understanding is wrong?
public static void main(String arg[]) {
int a[]=new int[0];
a[0]=5;
}
}
It will compile fine,when I run this code,its saying ArrayIndexOutOfBoundException....
As we know array declaration should have one integer value,even if I give -1 also it will compile. But in runtime it is saying NegativeIndex or ArrayIndexOutOfBound for -1 or 0 respectivley.
Why it is doing like this? While doing compiling itself why don't the compiler has do that? I accept for the variable initialization since it has clue for the variable in the compilation time,but for straight forward initialization like above should caught by the compiler... is my understanding is wrong?
Subscribe to:
Posts (Atom)
