The standard segment keeper FSC {(p2,fsc)} creates new (fresh) pages and installs them at the virtual address where they are needed.

The segment starts out with one node with an SSC = 3. That node remains the top node of the segment and its ssc changes as required. In segments of this type unused initial slots all hold DK(0). Other initial slots of nodes of these segments hold page keys or node keys with an LSS of one less than the lss of the node where they sit.

See (p3,vcsklogic) for the program logic of a real segment keeper.

There are two problems with this
The reader may fail to finish and thus eventually ruin the shared data.

It may be required to completely hide the actions of the reader from the writer.

One solution to these problems is to use the ideas of virtual checkpoint or snapshots {(p3,segcheck)} and take a snapshot of the data (which logic can be widely trusted not to fail) and let the reader work on this snapshot.
If the reader's activities are to be hidden from the writer it may be necessary to go to the extreme of providing regular checkpoints whether or not they are needed for a reader. They need not be taken more often than the atomic writes occur.
This scheme has the drawback that the readers may be working on stale data. This is a trade off that seems to me to be usually capable of reasonable resolution.

A virtual copy acts as a real copy for most purposes. Its cost may be very much less than a real copy. It never costs much more. It costs less because the real storage of which it is composed may be shared with the segment from which it was copied. This sharing ceases, for a given page, when the copy is modified.

See (p2,vcsk) and (p2,fs) about available segment keepers that implement some of these ideas.

Constant and Variable segments

If X is a segment and Y is created as a virtual copy of X then several situations arise depending of which of X and Y are modified after Y has been created. These comments apply only to integrated segment keepers.

If neither will change, memory keys to either are interchangeable and the copy operation consists of copying the key.

If X is constant after the copy but Y changes, then nodes and pages of Y that define portions of Y that are different than X are created for Y but other pages and nodes are shared. It is important that X need not be modified to perform the copy. This is the case that has been considered in current designs.

If Y is constant but X will (continue to) change {typical of a checkpoint} then it seems that the representation of X must be changed in order to perform the copy.

It seems this way because this is true of the only way we know to do this operation. Let the top node of X be NX. When a constant copy, Y, is to be made of X, a changing segment, the slots of NX are copied into the slots of an newly created node NY. A read-only segment key to NY now becomes the key to Y. The keys in NX are each made read-only. Subsequent attempts to modify NX will be provided for by X's segment keeper furnishing new nodes and pages to hold the data subsequent to the copy. As this occurs, the slots of NX will become read-write memory keys to sub-segments that have changed since the copy.

This has the curious effect of deferring and avoiding, in part, the cost of Y. There is a danger of confusion here: X's space bank may not have been selected to be able to support the real cost of Y. There is no easy way of segregating the cost of maintaining X and Y.

If X and Y both change after the copy it seems necessary to create a hidden constant segment, parts of which both will both share.
There seems to be no way to delete parts of the constant segment that are required by neither copy. Even when both copies are gone the constant segment may still be there!

In light of the above complexity we propose to support only the case where the copy changes while the original remains constant.
The other functions may be had by logic outside the segment. Suppose that we plan to take checkpoints periodically of segment X.

To do this we create a node N and distribute red segment keys to N to wherever we wish there to be access to the segment. N is formatted for a large lss and for only one initial slot which holds the segment key to the real segment. The checkpoints taker keeps a node key to N. When it is time to take a checkpoint, a call is made on the segment keeper to make the current segment read-only and provide a new read-write segment that is like the old segment.

The key to the new segment is placed in the first slot of N and we are done.

For that period of time after the old segment has been made read only but before the key to the new segment has been placed in N, we change the number of initial slots of N to 0. This way accessors of the segment will not experience segment faults. The accessors will be enqueued on a busy segment keeper for N. When the transformation is done the keeper will become available and the accessors will resume (perhaps with the help of the worrier).

Integrated and Standalone varieties
Standalone: The program described below builds virtual copies to segments to which it holds memory keys only.
This program will much simpler and efficient if background{(p1,backkey)} keys are implemented.

If MK is a memory key and VIRTUAL_COPY is from the public directory then VIRTUAL_COPY(0,MK==>c;VC) provides a virtual copy of MK. The pages of VC will initially be the pages of MK but with read-only access. A real copy of a page will be made by VC's segment keeper just before a store is allowed into VC. If MK is not changing the effect will be as if a real copy had been made. References to VC at addresses not defined in VIRTUAL_COPY will be initialized to zero without changing VIRTUAL_COPY.

Integrated: While virtual copies can be made of a segment given only a memory key to the segment. Substantial economies can be had by integrating the segment keeper of the copy in such a way that it has access to the structure of the original.
Sections (p2,vcsk) and (formative,vcseg) speak of segments with integrated logic that provide a virtual copy of themselves.

See (p3,vcsklogic) for some implementation details.

The three sections under this paragraph each describe a strategy for implementing virtual copies. I think we will do (p3,vcpyfsc) first.

Implement the facade function (p2,facadecopy). This has the disadvantage in some applications that the memory tree depth tends to be the product of the LSS and the number of layers of facade. Its generality (it can front any segment) wins in some cases.

Modify the logic of the segment keeper (p2,fs) to make it obey the virtual protocol (p2,vcsk). This lacks the generality of facades but avoids any extra memory tree depth.

Do the above and in addition replace the old create fresh segment operation {(p2,fsc)} by making virtual copies of a real, shared, all-zero segment of size 2**48 bytes. This has the advantage of removing one of the two kinds of segments kept by the segment keeper. A disadvantage is that the top node of each segment has one less initial slot and a fault for a new page goes through an intermediate stage of mapping in this ubiquitous zero page before it gets down to the business of giving you the page that is really required. This scheme wins big when the first references to a new page are read references that precede the first write references by a long time. I can't think of many such situations.

In common:
A segment operator takes a memory key and yields segment key.

Each of these operators operates on a given page or leaves it alone.

Which pages are operated upon is not described yet; presumably there will be some selective control over who can make what changes.

There are great economies when groups of 16**n pages are operated upon at once.

Some segments may have these functions built in, achieving greater efficiency.

Operator enumeration
Mask: The result has certain addresses invalid for either read or write.

Write mask: This operator yields a new memory key via which selected page addresses cannot be stored into.

New Page Upon Store: A new page is added at a p-slot when a store is first done there.

This operator requires a space bank too.

See (segment-indirect) and (p3,segkeeparmstr) for other memory tree programming notes.