Java can insert statistics calculations into the generated native code, and then after a while regenerate it to optimize it against the current runtime paths in your code!
Java compiles to bytecode, and the bytecode compiles to native code by the JIT.
Java gives you more, but it's not always up to you how it performs.
GC copies alive objects and throws all dead one, since GC does not need to do anything for the dead one only for the live ones, GC in theory is faster then the normal malloc/free loop for objects.
However, one thing is forgotten by most Java advocates and that is that nothing says that you will have to malloc/free every object instance when coding C. You can reuse memory, you can malloc up memory blocks and free memory blocks containing thousands of temporarily objects on one go.
If you only keep to simple math over a preallocate buffer, both Java and C compilers should spit out about the same code.
In Java the JIT has a specific amount of time to compile the bytecode to native code, it is not OK to spend all CPU resources for the JIT, since it runs in parallel with the code doing the actually work of your program. In C the compiler can run as long as it needs to spit out what it thinks is the most optimized code it can. It has no impact on execution time, where in Java it has.
In some extreme cases, the JIT may also choose not to JIT the code at all. This happens when a JITed method would be to big, 8K if I remember correct. A non JITed method has a runtime penalty in the range of 20000% (200 times slower that is, at least at our customer it was). JIT is also turned of when the JVMs CodeCache starts to get full (if keep loading new classes into the JVM over and over again this can happen, also happen at customer site).
At one point JIT statistics also reduced concurrency on one 128 core machine to basically single core performance.
So as i under stand,if i will calculate this expression : arr[i]=arr1[i]/arr2 it will take the same time in the 2 cases?
That last point sounds awesome, java do however come with some tradeoffs:
The difference are really the extra compile step, and in theory java should do a better work then your C compiler, and here's why:
With big heaps on Java, GC time increases, adding stall time. In some software it is totally OK with stall times during GC cleanup cycle, in others it causes fatal errors. Try keeping your software to respond under a defined number of milliseconds when a GC happens, and you will see what I'm talking about.
this answer is nice but it's not related to android. something should be said about if android lets you go around java with c++. it does. stackoverflow.com/questions/8922608/
to add to this. java is not good for parallel programming because oop is not good for that. also java doesn't have meta-programming that is as good as c++'s