> Well, if composition _is_ supported as a fundamental abstraction (and I
> think it should be), there is no reason for a NewSys address space _not_ to
> be simply a simple segment, which will presumably always be a composition
> of other segments or mappings.
>
>I think there is. The problem with assignment of fault responsibility
>is serious. One wants to be able to make a clear distinction between
>a fault in the object and a fault in the mapping. Segments make that
>distinction impossible. If memory objects nest, the assignment of the
>proper scope to a fault becomes ambiguous very quickly.
It's another "no right answer" situation: different types of "compositors" (is that a word? :-) ) are useful for implementing different things, and what a particular compositor is used for dictates what its page fault behavior should be. I'll provide some examples farther down.
>In addition, the usual case is large contiguous mappings of dense
>objects. Tree structures don't do this well.
You're assuming we do it exactly like KeyKOS did - as a page-table-like address translation tree where each level decodes 'n' bits of address space. That's not what we're planning to do. I don't have time to provide all the details now, but in short a mapping can be anywhere you want it, any size you want (within the limits of page granularity, of course), and can be composed together however you want. To answer the obvious questions that will undoubtably spring up: yes, we know of the potential performance problems during lookup on page faults, and have ways to deal with them; yes, it is possible to compose two overlapping mappings, resulting in an ambiguous address space, but doing so will only hurt the client of that address space; yes, may be possible to create loops, but doing so will only deadlock the client.
>Can you be a little more specific about how you intend to use
>composable memory objects and why the existing model in Mach is
>inadequate for what you need (other than the implementation)?
One of our domains of research is large, single- or few-address-space systems, where many different processes share an address space but still maintain separate protection domains, each "seeing" only certain subsets of that address space. One of the primary goals of this design is to make sharing between processes easier. While we certainly aren't going to make the Mach VM system force such a model to be used, we want Mach to support SAS efficiently. To do this, it needs to be possible for processes to pass around capabilities giving them access to different subregions of the address space, and it's easiest if an arbitrary set of mappings can be represented by a single capability in a structured way: for example, one capability representing the text, data, and bss mappings for a particular program.
Even if you don't buy into "the SAS thing" (I'm not sure I do :-) ), it's useful in other ways as well. For example, some optimized IPC mechanisms, such as fbufs (see the last SOSP proceedings) make use of limited shared memory mechanisms. Finally, as I already mentioned, mapping composition can be used to implement all kinds of neat abstractions outside of the VM manager, such as copy-on-write.
Here are a few examples of "compositors" I'd like to have in my bag of tricks. Of course, some of them may be easily implementable using others, and therefore don't need to be implemented separately; in fact it's likely that all of them can easily be implemented with one general-purpose object type. But right now I'm just rattling off examples.
Anyway, there are other possibilities that come to mind, I'm tired, and these should give you the basic idea.
Bryan