harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: Against using Java to implement Java (Was: Java)
Date Wed, 18 May 2005 22:13:34 GMT

On May 18, 2005, at 9:36 AM, Steve Blackburn 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.

I assume you mean that Modularization is orthogonal to this - that  
they are independent aspects?

geir

>
> --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.
>>
>>
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message