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.
|