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.200 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=nteUes9W1JDNp353F0Ky0tMNldX45oFu6d7XCjWA1NAGmlv+tDpduiOuGdajz9XwlPRYmt2zBQGONnuRE35YW1sFEeraiX6CTS0NlvEJBtNb+g4WMrBlVaUUW9a3AJg5fN3/zAYCcT1BJVrpSz7fE1DgNVYvxbXUDXr0xLNsDoU=
Message-ID: <892f710b050518070637147bdb@mail.gmail.com>
Date: Wed, 18 May 2005 15:06:01 +0100
From: David Griffiths <david.griffiths@gmail.com>
Reply-To: David Griffiths <david.griffiths@gmail.com>
To: harmony-dev@incubator.apache.org, Steve.Blackburn@anu.edu.au
Subject: Re: Against using Java to implement Java (Was: Java)
In-Reply-To: <428B44FA.3050503@anu.edu.au>
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>
	 <4dd1f3f005051805556d52eff5@mail.gmail.com>
	 <428B44FA.3050503@anu.edu.au>

I know, but despite the subject line my original point was about the
problem of modularizing a VM written in C.

Cheers,

Dave

On 5/18/05, Steve Blackburn <Steve.Blackburn@anu.edu.au> wrote:
> This subject has been covered in detail at least twice already.
>=20
> There is no need for any function call on the fast path of the
> allocation sequence.  In a Java in Java VM the allocation sequence is
> inlined into the user code.  This has considerable advantages over "a
> few lines of assembler".  Aside from the obvious advantage of not having
> to express your allocator in assembler, using Java also compiles to
> better code since the code can be optimized in context (register
> allocation, constant folding etc), producing much better code than hand
> crafted assembler.
>=20
> However this is small fry compared to the importance of compiling write
> barriers correctly (barriers are used by most high performance GCs and
> are executed far more frequently than allocations).  The same argument
> applies though.  The barrier expressed in Java is inlined insitu, and
> the optimizing compiler is able to optimize in context.
>=20
> Modularization does not imply any of this.
>=20
> --Steve
>=20
>=20
> Weldon Washburn wrote:
>=20
> >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.
> >
> >
>