On 5/9/05, Steven Augart <[EMAIL PROTECTED]> wrote: > > --- Tom Tromey <[EMAIL PROTECTED]> wrote: > > * Fragmentation. I think there are too many free JVMs. > > Amen to that. I hate to say it, since my own favorite VM is one of the > ones keeping that space big. But a "state of the art" optimizing > compiler stops being "state of the art" when the art progresses without > hte optimizing compiler getting upgraded too. > > > It ought to be possible, > > though difficult, to write a configurable core VM that can be reused > > by other projects. The idea here is, have a reusable reference > > implementation, and reduce writing a VM to writing an execution > > engine (and perhaps a GC). > > This idea sounds really cool in the abstract. I have difficulty > understanding what it would really mean in the specifics, though. > > I'd like to take off on a tangent here. At one point I had the naive > idea that I could make Jikes RVM able to play nicely with GCJ. What > really quashed the idea was the issue of garbage collection -- GCC is not > designed to pass type information down to the lower levels of the > compiler, so GCJ doesn't build a "gc map", which you need in order to be > use any GC other than a Boehm-style conservative non-copying collector. > In other words, GCJ is restricted to using a garbage collection that > looks for any bit patterns in the data that might be pointers, and it has > to assume that all of them are pointers. If I am mis-stating the > problem, I would appreciate someone publicly correcting me.
There are way more issues than just the GC, what about synchronization, for example? It must export a hook to the runtime executive to manage object synchonization so mixed code can work, doesn't seen to be hard (if it's not already implemented) but forbit advanced optimizations like inlining the synchronization code (ORP does that, I believe). The best way would be to have a full java binary ABI, but this is no simple task.
