Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of tromey@redhat.com designates
 66.187.233.31 as permitted sender)
Sender: tromey@redhat.com
To: harmony-dev@incubator.apache.org
Subject: Re: JIT vs. WAT
References: <F02EAE07A561584D92034BA84EE60123973981@eduau-exch.eduau.local>
	<db0b8c8e105fdd6838036929740a1c6a@earthlink.net>
From: Tom Tromey <tromey@redhat.com>
Reply-To: tromey@redhat.com
Date: 12 May 2005 18:41:28 -0600
In-Reply-To: <db0b8c8e105fdd6838036929740a1c6a@earthlink.net>
Message-ID: <m3sm0s2c07.fsf@localhost.localdomain>
Lines: 42
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

>>>>> "Bob" == Bob  <citibob@earthlink.net> writes:

Bob> There's a lot of discussion on JIT vs. WAT.  I think I can lay down
Bob> some framework on the issue.

Bob> WAT-compiled code requires a smaller runtime system, their programs
Bob> load faster, they probably use less memory at runtime, and they run at
Bob> a (more) consistent speed.  This makes WATs especially well-suited for
Bob> PDAs and other mobile devices, which may not have an extra few dozen
Bob> megabytes to spare for a full JIT-based Java system.

And, we think, desktop and small utility use, where the benefits of
reduced startup times and shared libraries are felt more strongly.

Bob> GCJ begins to fall short where you wish to use Java's dynamic
Bob> loading/linking capabilities.  Classes must be loaded dynamically,
Bob> garbage collected when they're no longer used, and integrated with the
Bob> existing code.  They must be bytecode-verified and sandboxed.  I'm
Bob> sure that someone who's really clever could make this all work under
Bob> GCJ.

We've basically done all that in the gcc 4.0 release.  There is a new
ABI that does all its linking at runtime (at some performance cost).
Verification works even for precompiled code.  The origin of classes
is irrelevant; they are looked up in a shared library database; I like
to describe gcj as a "caching jit".

You can even run gcj itself as a jit (in response to an uncompiled
class, compile it to a .so that is then loaded), but this mode still
has some scalability problems.  This does mean that, at the moment,
things like runtime bytecode instrumentation (AOP and friends) don't
mix that well with the gcj approach.

Bob> Finally, as of last summer, GCJ was not "drop-in" compatible with
Bob> Sun's javac.  You cannot just take an Ant script and replace "javac"
Bob> with "gcj" and have it all work.

This is the role that the java-gcj-compat package fills.
jpackage-style alternatives basically solve all the problems in this
area.

Tom