David P Grove wrote:

Hi Dave and others,

If this will help to make MMTK a bit less dependent on JikesRVM (so I can use it in JNode also) that would be very great!

For that I suggest to make an RVM indepent prefix like org.vmmagic or something.


This email is mainly reporting some in-person conversations that happened last week when Steve Blackburn was visiting the US.  I'd like to reach a final consensus on this in the next few days so we can go ahead and start making the changes.

There is a proposal to move all of the "magic" currently mostly found in various classes in com.ibm.JikesRVM to their own set of packages.  This will (1) support some portability goals for MMTk and (2) enable a more precise definition of the 'magic interface' and possibly separate those aspects that are more vm-independent from those that are more Jikes RVM specific.  At this level I think this is fairly uncontroversial and unlikely to be that disruptive for users of the system.

The current proposal (as I recall it) is to have at least 3 new magic packages:
        <prefix>.unboxed (VM_Address, VM_Word, etc).
        <prefix>.pragmas (VM_PragmaUninterruptible, VM_PragmaInline, etc. and most likely VM_Uninterruptible as well)
        <prefix>.functions (Steve, did we have a better name? for the misc static functions now in VM_Magic).

The <prefix> is still an open issue.  magic?  vmmagic?  org.magic?  org.vmmagic? com.ibm.JikesRVM.magic?

A related open issue is whether or not we should remove the VM_ prefix from classes as we put them into these magic packages.  On the one hand, this is "nice" and makes the resulting class names less Jikes RVM specific (possibly good for MMTk), on the other hand it is a somewhat massive rename (impacts a large number of files) and thus could be fairly disruptive for people who maintain patches/local cvs with differences from the cvs head.

I have a personal opinion of course, but am holding back to avoid biasing the discussion ;-) On this second point, I'd really like to hear from people not on the core team who maintain largish deltas from the system.  It seems to me that they are the most likely to be impacted (or not) by this kind of wide-spread renaming.