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 david.griffiths@gmail.com
 designates 64.233.162.207 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=QvxAoSLotgGMhb/gMkUkaZ+MLNiAsItjGX3nktSZMMELb5iMcjVioHIGyKhqLd8z0uUU4zSVqDuN9tLunRAkA+X/fA+24MxpV42oxeXS5gCJbfQOfSSEE9vH0LFhAT1amBR3a75ZG4Nnx/naotLOYYu/RTHPBF/9U/XTyRLn6b4=
Message-ID: <892f710b050518035272ab759@mail.gmail.com>
Date: Wed, 18 May 2005 11:52:05 +0100
From: David Griffiths <david.griffiths@gmail.com>
Reply-To: David Griffiths <david.griffiths@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: Against using Java to implement Java
In-Reply-To: <20050518.160432.719891952.shudo@aist.go.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <BDA3EAE8-EE72-4310-A0AC-F5424ADE048E@apache.org>
	 <892f710b0505170251627dea61@mail.gmail.com>
	 <m34qd1nzsx.fsf@localhost.localdomain>
	 <20050518.160432.719891952.shudo@aist.go.jp>

Well that's the theory but I think you'll find in practice that real
JITs cheat and inline object allocation using their knowledge of the
GC internals.

And there is no way that a JIT is going to implement synchronized
methods by doing a "monitorEnter" function call!

Dave

On 5/18/05, shudo@computer.org <shudo@computer.org> wrote:
> There is an old document describing a JIT interface though ORP should
> be more advanced, for example, as having GC interface.
>=20
>   The JIT Compiler Interface Specification
>   http://java.sun.com/docs/jit_interface.html
>=20
> Sun's Classic VM, which was a reference VM, of JDK 1.0.2 and 1.1.X
> implements this interface and it was modified a bit for J2SDK 1.2.
> There were actually multiple JIT compilers based on this JIT interface
> including Symantec JIT, OpenJIT, shuJIT and TYA.
>=20
> This interface is not enough to support advanced optimizations
> including adaptive compilation, which today's Sun's and IBM's runtimes
> do.  Adaptive compilation needs cooperation by an interpreter (or a
> baseline compiler) and I am not sure whether it can be factored out
> from the JVM core.
>=20
> From: Tom Tromey <tromey@redhat.com>
>=20
> > David> Maybe a concrete example would help. Let's say you have a GC mod=
ule
> > David> written in C. One of it's API calls is to allocate a new object.=
 How
> > David> is your JIT module going to produce code to use that API? Via a =
C
> > David> function pointer?
> >
> > Yes.
> >
> > One way is to mandate link- or compile-time pluggability only.  Then
> > this can be done by name.  Your JIT just references
> > '&harmony_allocate_object' in its source and uses this pointer
> > in the code it generates.
> >
> > The other way is to have the JIT call some central function to get a
> > pointer to the allocator function (or functions, in libgcj it turned
> > out to be useful to have several).  This only needs to be done once,
> > at startup.
> >
> >
> > For folks interested in pluggability, I advise downloading a copy of
> > ORP and reading through it.  ORP already solved these problems in a
> > fairly reasonable way.
>=20
>   Kazuyuki Shudo        shudo@computer.org      http://www.shudo.net/
>