harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Tromey <tro...@redhat.com>
Subject Re: State of the World
Date Mon, 16 May 2005 07:32:06 GMT
>>>>> "Ben" == Ben Laurie <ben@algroup.co.uk> 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.


View raw message