I know, but despite the subject line my original point was about the problem of modularizing a VM written in C.
Cheers, Dave On 5/18/05, Steve Blackburn <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. > > > > >
