Hey, Java code is compiled to bytecode which it is portable across many platforms. But Java also is JIT compiled which happens on the fly.
Does this mean Java is compile twice? first by us to produce the bytecode and the second by the JVM? Thanks.
+6
A:
TMK, when you compile you are compiling for the JVM platform. Then when you run the app on the JVM on any machine, certain parts of code that are used frequently get compiled into code native to that machine for optimization.
So in short: Yes, but for a very good reason
TheLQ
2010-08-01 19:45:06
This is correct; the JVM will further compile parts of the code into native machine code so it can run faster (since there's no more abstraction between the native machine code and the Java bytecode). The act of this runtime compilation is referred to as JustInTime (JIT) compilation.
Shakedown
2010-08-01 19:51:52
So only the frequently used code is JIT compiled? This is a new info to me, thanks.
El Gusto
2010-08-01 20:18:03
It might be more correct to say that the bytecode is *replaced* with equivalent native code, instead of being *recompiled*. Compilation is generally a much more complex process than code replacement/optimization.
Loadmaster
2010-08-01 20:28:21
To be more precise, "certain parts" -> "methods" and "used frequently" -> "reach the count from system property os400.jit.mmi.threshold"
h3xStream
2010-08-01 20:50:21
A:
When java creates a .class, it's not byte code, your computer doesn't understand it. The Java VM does the work of translating it into something the computer can actually understand.
Nicholas
2010-08-01 19:46:48
I think when Java creates a .class, it *is* bytecode. I think what you mean is it isn't a native binary that a computer can run.
Bakkal
2010-08-01 19:50:55
That's incorrect, the `.class` files are bytecode, which the JVM knows how to execute. The JVM will only translate the bytecode into native machine code when it determines that the performance could increase if certain parts of the application were executed as native machine code without having the layer of JVM abstraction to go through all the time.
Shakedown
2010-08-01 19:53:55
+2
A:
Does this mean Java is compile twice? first by us to produce the bytecode and the second by the JVM? Thanks.
You could say that, once using information available in the source code (compiler), then the other in runtime (JVM/JIT) when information about the specific hardware is available, along with some profiling to decide what gets to be JIT-compiled or not.
Bakkal
2010-08-01 19:49:20
+4
A:
Your code may be compiled from bytecode into native code by the JVM if it's "hot enough"; and it may be so compiled several times, with the old version being discarded, depending on the runtime characteristics of your program.
The JIT is a complicated beast; in fact the Sun JVM has two JITs (-client and -server) that behave differently from each other, and some implementations even support both JITs running together (so you may have interpreted bytecode running alongside code compiled by two different JITs in your application).
I recommend you read more about Hotspot (the most common JIT since it's the Sun one) if you're really interested in this subject. You can start at Sun's page.
vanza
2010-08-01 19:50:54
Why it can be compiled several times? why the first time compiled bytecode isn't sufficient?
El Gusto
2010-08-01 20:20:49
Lots of things can cause the JIT to discard old compilations; things as simple as taking a different branch that was never taken before can cause the JIT to issue a "fault" and discard the old code (which was based on the same branch being taken every time).
vanza
2010-08-02 03:00:58
Also sometimes it compiles code "just in case" even if the method wasn't executed before. Then, when the method is called, it recompiles it to a more optimized version.
tulskiy
2010-08-02 05:18:19
A:
The mechanism is
Java -> Byte Code (compiled By java compiler)
ByteCode -> native code (interpreted by JVM)
Anindya Chatterjee
2010-08-01 19:57:35
A:
Short answer: Yes kind of.
The longest one: That is 2 different things. The first compilation is from the source code to the bytecode often call the intermediate representation (IR) in the compilation field.
Then the VM take the bytecode and translate it back to the native code on which platform it is installed.
This is 2 completely different kind of compilation. The second is not even quite a compilation since there is no syntax checker scope analyzer... Well there is some check but not the same kind of check that you have in a compiler.
mathk
2010-08-01 20:01:50