Re: [Jikesrvm-core] vmmagic duplication

[Steve B. <Ste...@an...>]

Right.   The reality is that four VMs are now using derivatives of  
this code base (us, harmony, moxie, and jnode).  And in addition to  
this, we have a fifth dialect, which is the vm-dependent version used  
within the Jikes RVM core.  Furthermore, the prototypes themselves  
are something of a mess, with incomplete/missing/incorrect comments  
in a number of the classes.

I am doing two things.  First, I am rationalizing what we have in the  
hope that we can reduce our five similar (but different) versions  
down to one.  Second, I would like us to do a principled re-think of  
vmmagic, something we started a year ago.  For now I just want to  
consolidate what we have and produce a "0.1 release" (ie a trivial  
jar) which simply reflects a cleaned up status quo.  Hopefully that  
will reduce the pressure for a five-way fork, which I think would be  
really wasteful.  Having done that, we can move on to improve vmmagic  
in a variety of ways.  With the PLDI deadline and other pressures, I  
don't expect to actually get around to it till next week.  The more  
substantive improvements and a "1.0" version of vmmagic are something  
that I anticipate emerging on this list over a number of months, not  
something I'm about to attack right now.

I'm not sure what we do about creating ObjectReferences.  Arguably  
this is an orthogonal issue (something of a vm-specific bootstrap),  
and one that is handled by the other vm-specific magic (there's  
plenty of it in VM_Magic).

Thanks for pointing out that the bootimage writer needs a different  
implementation of the intrinsics.  Since we're using a regular JVM to  
build (with no compiler intrinsics), this means expressing everything  
in Java in the context of our boot image writing framework.  In some  
other JVMs this is not true, either because they are not Java-in-Java  
(harmony), or because they have a different boot image writing  
process (moxie).

--Steve