Re: [Jikesrvm-researchers] prepare and attempt

[Chapman F. <fl...@ce...>]

Dave>
> Adding a VM_Magic.CAS is probably the wrong approach.  Adding
> VM_Synchronization.compareAndSwap (implemented using prepare/atrempt) would
> be better, but code using it would probably have some slight performance
> hit on PowerPC.  I'd hope that JMMtk would avoid using VM_Magic.
> prepare/attempt almost entirely in favor of higher level synchronization
> operations already provided (or to be added) in VM_Synchronization et al.

Here's another idea - in attempting to minimize and tidy the interface between
VM and MM, I've already floated the idea of consolidating into VM_Address some
of the casting (fooAsAddress, addressAsFoo) and dereferencing
(get/set<datatype>) methods that are now provided by VM_Magic. They were put
in VM_Magic before there _was_ a VM_Address, but now that there is one and the
same kind of compiler hijacking is used to implement it, it seems like a very
natural place to put methods that cast or dereference Addresses; and they are
syntactically prettier as instance methods - VM_Address foo;
foo.getInt() instead of VM_Magic.getMemoryWord(foo).

If this idea makes sense, it may also make sense to have a compareAndSwap
method on VM_Address as well.  This could minimize the number of VM_*
classes that have to become part of the JMTk - VM interface.  Certainly
it would be great to exclude VM_Magic from that interface; perhaps something
like VM_Synchronization could be part of the interface if it would be widely
regarded as a non-arbitrary, parsimonious basic set of facilities any JMTk
VM will want to implement.

Do you know of any work toward identifying a canonical set of lock-free data
structures? Maybe that would provide a starting point for some higher-level,
machine-independent facilities that could then be transparently implemented
with lwarx/stwcx on PPC or the most appropriate instructions on other hardware.

-Chap