Ganesh Swami said the following on 01/08/04 13:57:
"GV" == Gopalarathnam V <askgopal@xxxxxxxx> writes:
>> A JIT has better understanding of the runtime environment than a
>> compiler (ahead-of-time) and can therefore better optimize the
>> generated native code.
GV> Are you trying to say JITs can optimize native executables?? Why
GV> should native executables be optimized by JIT? They don't
GV> require any Just-In-Time support anyway, they're just
GV> "interpreted" by the processor.
Hmm, I think you have misunderstood my statement. I apologize as it
was written in a hurry.
(lets go back to our conventional definition of interpreter and compiler.)
A real interpreter, as in GW-BASIC for example, reads a single block
of code and executes it. Simple stuff.
A AOT compiler reads the code and generates native code. The generated
binary does not require anything special in order to be executed (or
"interpreted" as you would like to put it).
Until here, we are on the same page.
But in the case of a JIT, the section to be executed is read and
compiled to native code at *runtime*. JIT stands for Just-In-Time
COMPILER, but the word compiler is usually not tacked on. So, the Sun
VM actually has a compiler underneath which optimizes bytecode.
There are loads of things that can be done better at runtime, loop
unrolling for example. Sun's HotSpot technology identifies sections of
code which can be optimized leading to better performance at times.
GV> GCC 3.2.3 and other later versions code optimizations are
GV> comparable with Intel compilers now... they do all those
GV> branch optimizations, CSE optimizations, etc...
I would be grateful if you could point me towards a taxonomy of
GV> I'm not talking about compilers for languages like Java which
GV> don't generate native executables.
Neither am I, if you meant 'javac'.