On 5/25/05, Steve Blackburn <[EMAIL PROTECTED]> wrote: > I agree it is orthogonal to the language chosen to write the JIT. It > is not orthogonal to the language chosen to write the GC. > > As you say, you really want the barrier expressed in either Java, > bytecode or IR. So you could write your GC in C and then specially > code up your barriers and allocation sequences in Java or bytecode > (coding in IR immediately introduces a dependence between your GC and > a particular compiler). In this case you're no longer coding in C (to > paraphrase Geir ;-). You're coding in Java|bytecode|IR and C. Perhaps > the mix of Java and C within a core element of the GC would be > manageable. But why torture yourself? More importantly, if your goal > is performance, modularity and flexibility (MMTk supports 8 or so GC > algorithms), then treating barrier implementations as a special case > is needless pain.
One reason is that Harmony will need to plug in GCs other than MMTk. Another reason is that in the long term the JVM's memory manager (GC) probably ends up being merged with the OS's memory manager. Most OS kernels are written in ansi C today. A Harmony migration path that allows JVM/OS integration would serve this project well. > > A much better example is the allocation sequence for a free list > allocator (a non moving allocator is an important choice in some > settings). Interesting. I remember hearing that free list allocators are useful for embedded applications where RAM is constrained. In the embedded market, I remember hearing an interpreter is preferred because the footprint bloat of adding a JIT is unacceptable. Also for many embedded situtions, the performance of the java code is not the top concern. In other words, inlining GC alloc and write barrier is not useful to the embedded JVM marketplace. Do you foresee or know of uses other than embedded where a free list allocator is useful? If anyone in the embedded JVM market is reading the above, can you confirm/deny the above statements? I am curious what inlining the entire free list allocator does to code size. I worry about code bloat. Perhaps you can send me pointers to the analysis. > As I said above, I don't forsee inter-module calling as a likely > source of performance concerns. I have advocated right from the > outset and will continue to advocate a framework that allows modules > to be written in either Java or C. > > I hope this clarifies some of the issues. Thanks Steve for the clarification. This helps. -- Weldon > > Cheers, > > --Steve > >
