Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: [OT] RE: Java on Multi/Dual Core
Date: Wed, 23 May 2007 10:40:01 +0100
Message-ID: <DDBBD1E00935D144AB9563D57EF98D624EF31C@raccoon.melandra.net>
Thread-Topic: [OT] RE: Java on Multi/Dual Core
Thread-Index: AcedHGd4SrT6tk5qSsqX63cMfrffbAAAIITQ
References: <734400.30601.qm@web50010.mail.re2.yahoo.com>
From: "Peter Crowther" <Peter.Crowther@melandra.com>
To: "Tomcat Users List" <users@tomcat.apache.org>

> From: Vacuum Joe [mailto:vacuumjoe@yahoo.com]=20
> 3. Java is not interpreted.  It is compiled machine language=20
> code, just like C or C++.  Yes, that's right.  The JVM uses=20
> something called a JIT to compile much of the Java bytecode=20
> all the way to fully native machine language, which is often=20
> better quality and faster than C++ or C derived machine=20
> 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