[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Dec 1 14:26:24 1992 
Subject:persistence 
From: Robin Popplestone  
Volume-ID:921202.02 

In the original POP-2 tagging scheme, which exploited the fact that
high-order address bits were ignored by the hardware (so that POP integers
were machine integers) there was originally a spare tag combination that
we thought to use to support persistence. But we never implemented
anything.  Mike Foster & co devised a form of persistence for ABSYS at
about that time I seem to recall.

Turning to the present, there would seem to be no insuperable obstacles  to
a persistent  POP  (for  a single  user  on  a single  machine)  even  as a
development of POPLOG. If  programs are constrained  to not using  fast_...
procedures, and  the mishap  mechanism is  appropriately disciplined  (upon
which I have in the  past addressed the pop-forum) then  it can be used  to
trap access to  data-objects that are  not in main  memory. Any POP  object
could be "kicked  upstairs" to backing  store leaving just  a stub in  main
memory, containing a backing-store reference..  Trying to apply a  selector
function to  such a  stub  would then  cause the  object  to be  read  into
main-memory, with  an indirect  pointer  being inserted  in the  stub.  The
garbage collector would have to be modified to


(a) "Short circuit" such indirect references (there is an obvious
resemblance here to some of the techniques for lazy evaluation).

(b) Eliminate stubs that were only referred to by other stubs.


Procedures are a special case here, since they may be called without
questioning whether they really are procedures. But they can be treated
by introducing "procedural stubs" which are simply a closure of a
"call_from_backing_store" procedure.

Of course there would remain many issues of management of persistence to be
addressed. When object O is fetched from backing store, do its "friends"
also come down, and if so, how are they united with stubs that refer to
them?  What is the basis for deciding which objects are banished to backing
store?

Once we move away from the "one user on one machine" scenario, various
other issues come to the fore.  A procedural object has to be represented
in a machine-independent form (which cannot be source code, since the
machine-code object that results from the compilation of source depends on
the context in which the source was compiled). Issues like transactions,
and protection have to be addressed.

Robin.