Gabriel Sechan wrote:
From: Wade Curry <[EMAIL PROTECTED]>
So, what is the difference between JIT compiling and just
interpreting and saving the compiled objects (runtime compiled)?
Java obviously gets compiled in a separate step, rather than
happening at the time of the first execution; is there something
special about byte compiling Java code that would differentiate it
in other ways from the interpreted model?
Java compiles its byte code (or some portion of it) into native asm at
run time, and keeps the native asm around. Same idea, one step
further. It may get it a smidge more performance that way, but for the
most part its a buzzword Javaites use so they can claim they're better
than interpreted languages.
If you're referring to byte-code generation, I think you are missing out
on a number of it's advantages (and yeah, the performance advantage is
puny with modern desktop/server systems, although still useful in an
embedded context):
1) Allows for some verification of correctness (static checking) without
execution.
2) Allows for syntax level changes in the language to be hidden from the
runtime (this is a biggie that I've been burned on with several
scripting languages).
3) Simplifies the parsing of code at runtime, which tends to reduce the
number of possible exploits.
4) Byte codes provide a nice entry point to inject profilers and other
tools.
5) Allows for a single runtime format to support a wide variety of
languages and platforms (admittedly, the JVM specification is not
particularly kind to alternative languages, but it is pretty kind to
alternative platforms).
From a design point, it actually makes a lot of sense to have
byte-codes be your native distribution format (and it's worth noting
that technically the JVM spec supports having native code embedded in
there too). Why bother having the runtime deal with human-readable code
when machines are going to be the only ones reading them?
It's worth pointing out that Java is far from the only language using
bytecodes as the typical runtime execution model. Certainly Emacs users
tend to heavily favor using bytecodes (and the payoff on space savings
is impressive). Smalltalk runtimes typically generate bytecodes/objects
at save time, and then run from that. Then there's all the .NET
languages. A number of LISP systems do this as well. In general, it's a
pretty common strategy for "system" languages with dynamic binding (as
opposed to "scripting" languages).
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
