Why is it that bytecode might run faster than native code [closed]

Question

Java is slow.

That's more than an "urban legend", it seems to be a fact. You don't use it for live-coding because of latency and you don't use it for clusters/parallel computing. There are thousands of benchmarks out there, specially "Java vs C# vs C++".

http://benchmarksgame.alioth.debian.org/

According to the above site, not only is Java performance almost as good as C (far from the rest), but Scala and Clojure (both functional languages which runs on the JVM) both have a better performance that OCaml, Erlang.

And there are a lot of "Java is faster then X" out there, also (for instance, a question here on SO: Java Runtime Performance Vs Native C / C++ Code?).

So Java seems to be fast, for certain cases. Can someone explain why?

Why is it that bytecode might run faster then native code, in some cases, given dynamic code (Scala, Clojure) and garbage collection? How come if it is faster, there is still latency?

It seems to be a contradiction here, can someone shed light?

Answer 1

In the book masterminds for programming, James Gosling explained:

James: Exactly. These days we’re beating the really good C and C++ compilers pretty much always. When you go to the dynamic compiler, you get two advantages when the compiler’s running right at the last moment. One is you know exactly what chipset you’re running on. So many times when people are compiling a piece of C code, they have to compile it to run on kind of the generic x86 architecture. Almost none of the binaries you get are particularly well tuned for any of them. You download the latest copy of Mozilla,and it’ll run on pretty much any Intel architecture CPU. There’s pretty much one Linux binary. It’s pretty generic, and it’s compiled with GCC, which is not a very good C compiler.

When HotSpot runs, it knows exactly what chipset you’re running on. It knows exactly how the cache works. It knows exactly how the memory hierarchy works. It knows exactly how all the pipeline interlocks work in the CPU. It knows what instruction set extensions this chip has got. It optimizes for precisely what machine you’re on. Then the other half of it is that it actually sees the application as it’s running. It’s able to have statistics that know which things are important. It’s able to inline things that a C compiler could never do. The kind of stuff that gets inlined in the Java world is pretty amazing. Then you tack onto that the way the storage management works with the modern garbage collectors. With a modern garbage collector, storage allocation is extremely fast.

Answer 2

Fast JVMs use Just-In-Time (JIT) compilation. The bytecode gets translated into native code on the fly at run time. JIT provides many opportunities for optimization. See this Wikipedia article for more info on JIT.