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 <[EMAIL PROTECTED]> wrote:
I think it's too slow to have the overhead of a function call forYes. I agree. A clean interface would have a function call for every
every object allocation. This is the cost of modularization. I doubt
any of the mainstream JVMs you are competing with do this.
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.
