[OT] RE: Java on Multi/Dual Core

[Peter Crowther <Pe...@melandra.com>]

> From: Vacuum Joe [mailto:vacuumjoe@yahoo.com] 
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org