At 14:06 -0800 1/2/98, Jonathan Shapiro wrote:
>Norm writes:
>
>>I suppose that the shortest description of the main benefit of background
>>logic is that it lets you make a copy-on-write version of a segment to
>>which you are only given RO access. There should be an easier way, however!
>>I think that it was used in Unix simulation.
>
>I am missing something. It seems to me that the same copy strategy used by
>VCSK/ZSK can be used to accomplish this -- indeed, in EROS the two are
>actually the same keeper.
The logic of neither of the above keepers is able to take an arbitrary
memory key
and provide a new key which can respond to stores by copy-on-write logic
(so as to produce a new segment even when the original segment remains
unmodified).
>
>One difference between VCSK/ZSK and this case is that the R/O segment is not
>guaranteed to be fully populated with zero pages. This is perfectly okay,
>as the keeper can populate the foreground with zero pages when DK(0) is
>discovered to have been copied into a foreground node.
You cannot copy memory keys from slots of the old segment with only a memory key to that segment!
>As we thought about the dionysix implementation, we came up with a place
>where it looked like background segments were useful: demand-constructed
>segments that are multiply mapped. The problem is that the base object is
>not frozen.
>
>Suppose domains A and B both wish to have access to some memory object M,
>which M is a demand-allocated object. If the ZSK/VCSK strategy is applied,
>then the node structure of M is lost as the object is lazily copied forward,
>and subsequent population of node slots within M may not be propagated
>forward correctly. That is, use of background segments in this way
>alleviates the requirement that the r/o segment be frozen.
>
>Does this seem plausible? If so, then I have my example and I'll keep the
>implementation, as I shall surely need them for the dionysix implementation.
>
>
>shap
There are a variety of possible functions you might want. You have described a couple. We planned to do a segment keeper that would at least do the address space semantics for Unix fork. Page states not required by either clone would immediately or eventually be reclaimed. Considering that either version of the address space might itself be cloned confused the situation. We did not have a concrete design. It was not clear that this semantics was useful except for supporting Unix. It did have the advantage that it the semantics were easy to express. I thought for a while that I had an even more general yet simpler scheme. I didn't work out the details, however.
Norman Hardy <http://www.mediacity.com/~norm>