harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Weldon Washburn <weldon...@gmail.com>
Subject Re: Against using Java to implement Java (Was: Java)
Date Wed, 18 May 2005 12:55:30 GMT
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.
> 
> Cheers,
> 
> Dave
> 
> On 17 May 2005 18:27:42 -0600, Tom Tromey <tromey@redhat.com> wrote:
> > >>>>> "David" == David Griffiths <david.griffiths@gmail.com>
writes:
> >
> > David> Maybe a concrete example would help. Let's say you have a GC module
> > 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
> >
>

Mime
View raw message