efficient viewpoints in Self

[Jecel Assumpcao Jr]

It is possible to transform the Self virtual machine into an Us one 
(see "A Simple and Unifying Approach to Subjective Objects", 
http://citeseer.nj.nec.com/smith96simple.html ) that is acceptably 
efficient. The solution is simple enough and obvious enough that I feel 
very silly having taken a whole year to see it.

The basic idea is to extend customization from {source method, receiver 
type} to {source method, receiver type, viewpoint}. For N active 
viewpoints that would make the code cache N times larger, which is very 
bad. Unless we do "selective customization" as I described in some 
previous messages or some comparable scheme. Then only methods that are 
actually called and are affected by a change in viewpoint will have 
multiple versions in the cache. There would still be a time cost since 
whenever a given method is called from a new viewpoint we have to redo 
all the lookups to see if the code can be shared or must be recompiled, 
but that shouldn't be too bad.

That structure of the objects in memory would have to be slightly 
changed. The maps would have a list of slots for each layer and lookup 
would have to visit these "pieces" in the order indicated by the 
current viewpoint. The objects themselves would be just single 
sequences of words. Imagine that each layer is stored in a separate 
snapshot file and that a given object has four data slots and points to 
a map with pieces from layers 1 to 7. Now we read in two files which 
will add a layer 8 and a 9 to the map. Layer 8 includes two data slots 
and these are mapped to words 5 and 6 in the object (which has to be 
extended, obviously) and layer 9 has one data slot mapped to word 7 in 
the object.

Note that these extensions don't have any effect on code that has 
already been compiled since none of the previously available viewpoints 
made any use of layers 8 or 9. The order of the mapping between data 
slots in the layers and words in the object is not important as long as 
it doesn't change while there is compiled code that depends on it. 
Reading in a layer might cause objects that previously shared a map to 
go their separate ways, but that is not a problem. Note that if we can 
flush viewpoints and layers from the system, some objects could be left 
with unused words in the middle of them (we don't compact), but I don't 
think this is a big deal either.

If only one viewpoint and one layer are used, the overhead compared to 
the current VM will be very small. So the extra stuff doesn't cost you 
unless you actually need them.

I'll have to rewrite my "persistent object store" swiki page to be 
compatible with this proposal.

-- Jecel