God, I feel so awkward asking this. But someone recently asked me whether the java compiler (javac) and JIT compiler are the same thing (I said yes :roll: ). What's the fact? [ January 20, 2003: Message edited by: Debashish Chakrabarty ]
No, it's not... javac compiles your Java source code to Java byte code. The Just In Time compiler (or, in newer JDKs, the Hotspot Engine) will compile that byte code to native code at runtime. It is part of the Java Virtual Machine.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Thanks for replies. I also read that JIT compiler is a misnomer for its actually an interpreter. While compiling (or should I say interpreting) the byte code to native code it also handles any optimization if required. Is it right so far? Now my question: does that mean that there will be one javac for all OSs but different JITs for different OSs? Don't stare me so hard, I really am a genuine SCJP [ January 20, 2003: Message edited by: Debashish Chakrabarty ]
Think of the JIT compiler as a 'translator'. The javac compiler translates your .java sources to bytecode. Bytecode is a form of machine code, suitable for a (non-existing) processor. The Java virtual machine implements this processor. So, basically the JVM can be seen as an interpreter: it interprets those bytecodes. The JIT compiler instead, translates these bytecodes to *real* machine code. This real machine code can be executed by your *real* processor, so no interpretation by the JVM is necessary anymore, hence the speedup. kind regards
Debashish : The known fact that Java is compiled into byte code that makes it different and slower than C++. C++ is compiled to machine code. Now Java is compiled to byte code from javac, an interpreter so it is portable. To speed up things, the JIT compiles it to byte code, JIT = Just in time compiler, compile on the fly, whatever you want to refer to it as... JIT uses a Look Ahead feature and compile your bytecode into the appropriate binary code before executing it. It doesn't convert on a permenent basis so there is no EXE file created. It does this every time you executes your application. If you have JDK/JRE 1.3 or above, there is a JIT already implemented by default. Hope this helps!
One java compiler (wrote in Java) for all OS. (But each OS have different "starter" - javac.exe for Windows, as I think it start JVM with the java compiler) /The compiler convert source Java code to class file contains java byte-code and some tables./
/JVM = interpretator or JIT or HotSpot, execute java byte code./ Different JIT for different mashine architecture. (also different JIT for different OS in the same mashine, because jit used multithreading, thread synchronization, memory allocation - and other OS dependant things) Hot Spot = interpretator + JIT + ("hot spots" = most usable parts) finder. Starts as interpretator, and by the way change some parts of java byte code, to native code. (probably drop native code and restore byte code if the part now not in "hot" usage ??) [ January 22, 2003: Message edited by: Igor Ko ]
Thanks to all posts! I was only trying to digest Jos' reply when the replies of Chad and Igor confused me totally. As far as I understood: (1) javac is java compiler (infact an interpreter) that creates bytecode (same for all OS) from source-code. All OS will have the same javac. (2) Before JIT the JVM (different JVMs for different OSs) used to "interpret" the Bytecode into machine code. (3) Just-in-time compiler was introduced to make the activity in (2) faster Curse me but I don't want to get into the Hotspot thing right now. Can the ranchers confirm or object to the above, point by point, please and grant me my nirvana! [ January 22, 2003: Message edited by: Debashish Chakrabarty ]
Joined: Nov 22, 2008
You're mixing up the semantics of 'compiler' (or 'translator') and 'interpreter'. A compiler or translator translates one language to another language. Usually a 'high level language' (such as Java or C++ or whatever) gets translated to a 'lower level language' such as machine code or bytecode. The latter actually is machine code for a non-existing machine. After translation (or compilation) is done, you still have to 'execute' or 'interpret' the resulting language, or 'instruction set' as they call it when we're talking low level languages, to get your results. Now, how does this all apply to this mysterious Java bizniz. Suppose you write something like this:
The Javac compiler might translate this code into something like this:
the stuff above represents the byte code, generated by the Javac compiler. When your JVM starts, it *interprets* these simple instructions and gets the job done, i.e. it acts as if it were a simple CPU executing (this is synonymous to 'interpreting') these simple instructions. These simple instructions above can be further translated to *real* machine code, say a SPARC processor machine code or a Pentium machine code. When real machine code is generated, there is no need anymore for the JVM interpreter to interpret those byte codes; the *real* CPU can handle the job, causing a major speed increase. The task of translating those byte codes to *real* machine code is the responsibility of the JIT compiler; it translates Java byte code to *real* machine code. Of course, this real machine code differs per processor, i.e. Pentium machine code cannot be run on a SPARC processor or vice versa. That's why those JIT compilers differ per platform. Now, this is what every JVM is facing: should it further translate those byte codes (using that JIT compiler) or should it interpret (or execute) these things itself? JIT compilation is just what it says: just in time compilation. Facing the choice of interpreting those byte codes itself (being slow) or compiling it into *real* machine code (by activating the JIT compiler) first and then let the *real* processor do the job, so the *real* machine code could get executed (or interpreted) by the *real* CPU is quite a choice to make. Suppose a particular piece of byte code must be executed or interpreted. What to do? Interpret it a bit slower or compile it to real machine code and let the CPU do the dirty job? What if this piece of code gets executed only once? Further compilation into real machine code could/would be a waste. But what if this piece of code happens to be the body of a loop that gets executed a zillion times? Compiling it into real machine code once wouldn't be much overhead compared to the increase of speed. This is where the hotspot compilers come in, i.e. they try to make an educated guess whether or not they should compile the byte code when the 'job has got to be done'. The behaviour of those hot spot compilers it quite fascinating: loops start off quite slowly and after a couple of iterations the hot spot compiler 'saw' that it's dealing with a 'hot spot' (hence the name) of code, so it translates the byte codes into machine code, so the JVM can relinguish control and let the real CPU do the job. kind regards [ January 22, 2003: Message edited by: Jos Horsmeier ]