> From: Vacuum Joe [mailto:[EMAIL PROTECTED]
> 3. Java is not interpreted. It is compiled machine language
> code, just like C or C++. Yes, that's right. The JVM uses
> something called a JIT to compile much of the Java bytecode
> all the way to fully native machine language, which is often
> better quality and faster than C++ or C derived machine
> language. Saying "Java is slow" is like saying "C++ is slow".
Mmm. As someone who's collaborated on a JIT VM in the past, I'd note
that there are some trade-offs. It takes quite a complex JIT to be able
to notice method calls on the first compiler pass that can be *reliably*
inlined, for example, simply because you have limits on the bytes and
cycles you can dedicate to a compile, and you generally don't have
complete information on the types and call graph as you compile. A
static compiler, by contrast, can allow itself the luxury of much more
complete call graph and type analysis. On the other hand, a good
dynamic compiler can keep statistics, notice common call patterns and
compile special cases for them on the fly, which a static compiler
generally doesn't do.
The net effect? It's rare for a JIT compiler to produce "better quality
and faster" code than a static compiler in the first instance, as it has
less information to go on. It's *theoretically* possible for future
compiler runs to produce more heavily optimised code*. The Self project
did some interesting things in this direction, but I don't know how far
down that road the various Java implementations have actually gone.
Chuck probably has more information!
- Peter
* And it's theoretically possible to run the analysis tools and
subsequent compiler passes on spare cores, which becomes very
interesting in a radical computing world where most cores are spare most
of the time...
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
