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 weldonwjw@gmail.com
 designates 64.233.162.201 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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=JqCnWbKOuQqnWUliMMwJLscAa2/xEzdYrYb0favNb+MLGLGvZgqH8ShxjGAopA3vtT3wvnSnCpn1ESoJMdAeFh+r/LPMAHbAesIcz2YKpokqYJNYD3YBTF9hDwZvPfeJHOWIysSpMuY3eoGXhqxBYTMC+KhqvjgE83TqiDU3wAs=
Message-ID: <4dd1f3f005051805556d52eff5@mail.gmail.com>
Date: Wed, 18 May 2005 05:55:30 -0700
From: Weldon Washburn <weldonwjw@gmail.com>
Reply-To: Weldon Washburn <weldonwjw@gmail.com>
To: harmony-dev@incubator.apache.org,
	David Griffiths <david.griffiths@gmail.com>
Subject: Re: Against using Java to implement Java (Was: Java)
Cc: tromey@redhat.com
In-Reply-To: <892f710b050518033033b503d7@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <BAY107-F262C95E9447CD9E4FEFF77ED120@phx.gbl>
	 <42845E09.7010507@algroup.co.uk> <4284E445.20303@apache.org>
	 <BDA3EAE8-EE72-4310-A0AC-F5424ADE048E@apache.org>
	 <892f710b0505170251627dea61@mail.gmail.com>
	 <m34qd1nzsx.fsf@localhost.localdomain>
	 <892f710b050518033033b503d7@mail.gmail.com>

On 5/18/05, David Griffiths <david.griffiths@gmail.com> wrote:
> I think it's too slow to have the overhead of a function call for
> every object allocation. This is the cost of modularization. I doubt
> any of the mainstream JVMs you are competing with do this.
Yes.  I agree.  A clean interface would have a function call for every
object allocation.  However if the allocation code itself is only a
few lines of assemby, it can be inlined by the JIT.  Using a moving
GC, it is possible to get the allocation sequence down to a bump the
pointer and a compare to see if you have run off the end of the
allocation area.
>=20
> Cheers,
>=20
> Dave
>=20
> On 17 May 2005 18:27:42 -0600, Tom Tromey <tromey@redhat.com> wrote:
> > >>>>> "David" =3D=3D David Griffiths <david.griffiths@gmail.com> writes=
:
> >
> > 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.
> >
> > Tom
> >
>