>>>>> "Ben" == Ben Laurie <[EMAIL PROTECTED]> writes:
Ben> Tom Tromey wrote: >> * Fragmentation. I think there are too many free JVMs. In particular >> the "C/C++-based VM" niche is over-full. 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). Ben> This is certainly my understanding of the "modularity" aim, and one of Ben> my two main interests in this project (that and security, natch). Ben> Like they said, pointers to where you think the natural fault-lines in Ben> a JVM are would be most illuminating. A few places where fault lines occur: * OS portability layer. This one is pretty obvious. * Architecture portability layer. This can range from very small (jamvm has some small amount of assembly for atomic operations) to medium (e.g., using libffi to enable calls to C functions), to very large (porting a JIT back end). * Execution engine choice. This is actually not uncommon as a configurability tweak. Some VMs come with "slow" and "fast" compilers; some, like kaffe, treat this as a compile-time choice, where you compile in the interpreter or jit you want; with gcj you can mix and match pre-compiled code with interpreted code (though on some of the less common platforms the interpreter is not available). * Garbage collector. A few VMs have experimented in this area. libgcj has a very primitive approach here, since it is basically tied to a conservative GC (but we have had at least one case where someone wrote their own replacement GC and substituted it). JikesRVM and ORP both have pluggable/reconfigurable GCs of some kind. My recollection from the ORP sources is that the JITs would call into the GC to find information about things like write barriers and whatnot. You can drill down a bit farther and look at a lot of ABI-type issues, like object layout, synchronization approach, exception handling approach, parameter passing, etc. In many cases there's no particular reason you have to definitively make the final decision up front. Instead, you can do things modularly and use inlining or similar things to remain efficient. What I'm trying to say here is that, of course you have to make concrete decisions when writing the VM -- otherwise nothing gets done. But, you don't generally need to spread these decisions throughout the code. Tom
