"Naresh Agarwal" <na******@informatica.com> wrote in message
news:2b*************************@posting.google.co m...
Hi
How does JIT compilers work? Does they first compile the *entire*
bytecode into machine code and then starts execution? Or they first
compile a method, execute that and then compile another method and
execute that and so on. Why it is called as "Just In Time"?
Interpreters also need to compile to bytecode before execution. Thus
whether a java bytecode is executed by interpreter or JIT compiler,
the compilation will be required in the both the cases. Then why does
JIT compilers are slower then interpreters in certain cases?
Also does the current JVMs (JDK 1.3 and 1.4) supports JIT? Which JVM
versions supports JIT?
Does HotSpot VM supports JIT?
thanks,
Naresh
(response cross-posted to c.l.j.a)
Interpreters must parse sourcecode/bytecode but do not neccessarily
"compile" it. Even if they do the compilation outcome can be some abstract
instruction set not matching any processor hardware (that would be called
something like bytecode).
The Sun JIT starts executing bytecodes directly and builds a statistical
analysis of which code gets executed how often. As soon as it decides some
code is up for JIT-ting it is compiled to native machine code to be executed
faster from that point on.
Personally I would have preferred precompilation of a complete class file as
soon as it is loaded. That is what I call JIT. The way it works now in my
opinion should not be called JIT but JTL instead (Just Too Late, obviously).
People at Sun are so charmed by the concept they came up with once that they
blindly cling to it. The simpler precompilation (backup up by a smart JVM
level caching scheme would be an enormous performance boost. They insist
that more efficient compilation/optimization is possible when runtime
characteristics are know (as they are during JTL compilation) but that is
bullshit. This delivers a marginal advantage over preanalysis that can never
make up for the time lost with a) interpreting code initially b) time spent
during compiling at runtime c) time lost because of not being able to cache.
The memory-use argument is silly except for j2me.
Understand me correctly: I love Java and think it is one of the best
software development of the past ten years. I agree that static compilation
is not an option but I think the .NET precompilation scheme is much simpler
and more efficient. The Java JIT scheme is only better in mostly academic
perspectives and unfortunately gives us a performance disadvantage in
comparison with .NET.
Now I mentioned .NET: I have been a long time Win32 developer (C++ from
about '92) and gradually shifted to Java about four years ago. Did not look
back until some .NET projects came up that needed resqueing. Looked at .NET
(Winforms, ADO.NET and ASP.NET) and was absolutely disgusted. .NET is gross.
Just my ?0.02,
Regards,
Silvio Bierman