🚀 go-pugleaf

In article <PCG.90Feb11205739@rupert.cs.aber.ac.uk> pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes:
>
>The general approach of doing memory mapped things is to assume
>that they exist independently from the process address space, and
>that you can map sections of the entity in sections of the
>address space; in this way an entity may be much larger than an
>address space (see how MUSS does it, SP&E August 1979).
>
>You separate address space from data space entirely; a job may
>have several data space segments that are not mapped in any
>address space window.
>
>If you allow a user program the ability to manipulate its address
>space map, this becomes very easy to do; you can even (like in
>Mach) have virtual data segments, where the address space fault
>handler fakes data instead of mapping in data space entity.

True.

>Once you have this, you discover all the problems with memory mapped
>entities. One can be easily solved, the other not so easily.
>
>The first is data space aliasing. You have portions of data space
>visible thru different ranges of address space, possibly multiply
>in the same address space, or multiply in different address
>spaces (shared memory). This is bad. The cure is to allow it only
>for irrevocably read only segments; the others can only be mapped
>in one place at a time; address spaces take turns at mapping a
>segment (this is the MUSS approach -- MUSS has convenient
>'messages' that pass around permission to map a segment). This
>makes for safe interprocess communication, and need not (on a
>suitable HW VM architecture) be inefficient at all.

I don't understand why this is bad. In the implementation I am familiar
with, users mapped in according to their needs and priveleges (if you
only had read access, that's all you could map in; if you had read/write,
you could do either). If more than one application mapped in read/write
they had to coordinate, but that wasn't too different to do. Perhaps my
confusion is due to an invalid comparison. KeyKOS segments only loosely
correspond to files and usually shared files were more convenient to
access using a file paradigm (like read/write/lseek) so that multiple
read/write access was managed transparently.
 
>The second problem is address space aliasing. This is that you
>may map the same segment at different times in different portions
>of the address space. This means that you cannot use absolute
>addresses in a segment (as well as the obvious semantic hazards).
>The *only* solution is to have a single address space for all
>processes, i.e. a capability machine (if you want protection
>:->).

If you mean a single level store that is used to build all other address
spaces, then I agree. That's the most successful way I've heard of (my
own experience in this area is limited, but I was fortunate enough to
work with exceptional people who had been studying this particular 
problem for a long time). Capabilities and objects sure make life simpler
here.

[other discussion]
 
>A very large database can be built of multiple segments, and if
>they are properly implemented there is really no limit of size,
>as you slide multiple windows over multiple segments. A suitably
>written library can make this virtually painless. Note that something
>similar is always needed, except on single very large address space
>machines.

An alternative is to use a segment definition that is independent of the
hardware limitation. This doesn't remove the multiple window requirement,
but, for most practical cases, does remove the need for multiple segments
for size reasons. In the case with which I am most familiar, the implemenation
allowed a segment size of 2**59 bytes on a machine whose physical segment
was limited to 2**24 bytes. You mapped in the part you needed, and the VMM
worried about the rest.

>--
>Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
>Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
>Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk

Terry

Disclaimer: I have no idea what Amdahl's views on these matters are.