aspose file tools*
The moose likes Beginning Java and the fly likes Stupid question? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Stupid question?" Watch "Stupid question?" New topic
Author

Stupid question?

Debashish Chakrabarty
Ranch Hand

Joined: May 14, 2002
Posts: 226

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 ]

Debashish
SCJP2, SCWCD 1.4
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
This is NOT a dumb question!!! There are probably 5000 folks wondering about this SAME question that are so thankful that you got the nerve to ask it
.


"JavaRanch, where the deer and the Certified play" - David O'Meara
Debashish Chakrabarty
Ranch Hand

Joined: May 14, 2002
Posts: 226

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 ]
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
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
chad stevens
Ranch Hand

Joined: Aug 20, 2002
Posts: 88
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!
Prakash Dwivedi
Ranch Hand

Joined: Sep 28, 2002
Posts: 452
How JIT is different from HotSpot, or HotSpot is just another name for more efficient JIT compiler.
[ January 21, 2003: Message edited by: Prakash Dwivedi ]

Prakash Dwivedi (SCJP2, SCWCD, SCBCD)
"Failure is not when you fall down, Its only when you don't get up again"
Igor Ko
Ranch Hand

Joined: Jun 24, 2002
Posts: 90
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 ]
Debashish Chakrabarty
Ranch Hand

Joined: May 14, 2002
Posts: 226

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 ]
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
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 ]
Prakash Dwivedi
Ranch Hand

Joined: Sep 28, 2002
Posts: 452
thanks Jos Horsmeier,
for wonderful explanation
Debashish Chakrabarty
Ranch Hand

Joined: May 14, 2002
Posts: 226

Superb Jos! Thanks a zillion! Never knew all this stuff.
[ January 23, 2003: Message edited by: Debashish Chakrabarty ]
John Lee
Ranch Hand

Joined: Aug 05, 2001
Posts: 2545
Well, no question in the world is stupid.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Stupid question?