[Jikesrvm-core] putting magic in separate packages

[David P G. <gr...@us...>]

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. 

--dave