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
This email is mainly reporting some
in-person conversations that happened last week when Steve Blackburn
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
"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
and possibly separate those aspects that are more vm-independent from
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
The current proposal (as I recall
is to have at least 3 new magic packages:
(VM_Address, VM_Word, etc).
(VM_PragmaUninterruptible, VM_PragmaInline, etc. and most likely
(Steve, did we have a better name? for the misc static functions now in
The <prefix> is still an open
issue. magic? vmmagic? org.magic? org.vmmagic?
A related open issue is whether or
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
on the other hand it is a somewhat massive rename (impacts a large
of files) and thus could be fairly disruptive for people who maintain
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
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