Re: wish list

[dib@signal.dra.hmg.gb (David Bruce)]

(   > > [ I claimed undo needed VM support ]
 )  >
(   > Would like to hear your ideas on this one in particular.  What are you
 )  > thinking?  A redo of the assignment primitive to keep a reference to the
(   > last N old values ??
 )
(   That would be a bit better than using something like "rawColor" slots
 )  to save old versions, but would not be too efficient - versions, like
(   wrappers, tend to spread and contaminate the whole system.
 )
(   Actually, I am not sure what should be done, but I feel it must be
 )  integrated with the garbage collector and the persistent store
(   system. The best idea I have seen so far is Paul Wilson's "Deamonic
 )  Memory", but he seems to have gone in other directions now. I can
(   try to get a reference, if there is interest. Anyway, his system
 )  would let you back up the whole system to any point in the past.
(   That is not what I want. I want to be able to back up a certain set
 )  of objects to any point in the past (and even have some of them
(   coexist with their current versions!).
 )
(   Of course there must be a high-level "hook" to all this so the user
 )  can control this from the user interface, but I don't think a good
(   solution can be made only at the programming environment level (though
 )  a cumbersome one could - a kind of copy-down in time :-)

Wilson&Moher's paper was in PLDI'89.

Greg Johnson and Dominic Duggan had a language called GL that allowed
one to revert to previous states, intended for exploring various
debugging techniques.  They had a POPL'88 paper; the journal version
(Computer Languages, 1994) has a little more about the implementation.
Using a caching strategy they found only a modest slow down (~30%),
though I don't know how what their benchmarks involved.

Greg Morrisett at CMU has also done related work: see his paper
"Generalizing First-Class Stores" in the 1993 State in Programming
Languages workshop; some of the Venari work follows similar lines.
Morrisett's work allows the state to be partitioned as you want, and
gives an explicit handle on the different states to which one might
wish to revert to.

Blowing my own trumpet, I am investigating the use of versioning like
this for parallel simulation, where undoing is an intrinsic part of the
(optimistic) protocols.  (Here "time" delimits the consistent states.)
Most systems expect the user to write the state saving code; I have an
"automatic" technique.  [As Randy suggests, I start by patching the
assignment operator; there's a bit more machinery needed so that one can
control what's going on.]  My results so far show that the performance
penalty is not totally punishing, despite (for my sins) working in C++
where allocating memory is more expensive than I'd like.  For more details,
see my paper "The treatment of state in optimistic systems" in the
9th Workshop on Parallel and Distributed Simulation (1995), or ask.


    David Bruce
----
post:  DRA Malvern, St Andrews Road, Malvern, Worcestershire WR14 3PS, ENGLAND
email: (internet) dib@dra.hmg.gb  or  dib%hermes.mod.uk@relay.mod.uk
phone: +44 1684 895112  **  fax: +44 1684 894389 or 894540  **  telex: 339747