harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Griffiths <david.griffi...@gmail.com>
Subject Re: Against using Java to implement Java (Was: Java)
Date Wed, 18 May 2005 14:06:01 GMT
I know, but despite the subject line my original point was about the
problem of modularizing a VM written in C.



On 5/18/05, Steve Blackburn <Steve.Blackburn@anu.edu.au> wrote:
> This subject has been covered in detail at least twice already.
> 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.
> 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.
> Modularization does not imply any of this.
> --Steve
> Weldon Washburn wrote:
> >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.
> >
> >

View raw message