harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackburn <Steve.Blackb...@anu.edu.au>
Subject Re: Against using Java to implement Java (Was: Java)
Date Wed, 18 May 2005 13:36:58 GMT
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.


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