The Mungi Manifesto
Philosophy
The design of Mungi is based on the following principles:
- a single, flat virtual address space,
- orthogonal persistence,
- a strong but unintrusive protection model.
The single address space incorporates all memory objects on all nodes in a distributed system. There are no user-visible memory hierarchies, no file system. Any memory object is potentially persistent, i.e. can outlive its creator process. All objects are uniquely identified by their virtual address, which is a 64-bit number. Any object is potentially accessible by any process, provided the process is authorised to do so. Sharing is trivially achieved by exchanging addresses (and passwords, if required).
As there is no file system, all the secondary memory in the system is nothing but paging store. The address of an object does per se not give any indication on where the object is located, and there is really no such concept as "location" at the user level. If a process references a non-resident object, the kernel will obtain a copy and store it in local primary memory. This is not different from paging in traditional VM systems, except that a page may be obtained from disk or across the network.
Memory is allocated in (page aligned) chunks called "objects". (Others may call them segments, but we wanted to avoid the connotation of segmented memory.) An object is the unit of protection. No other structure on objects is assumed by the system, but higher software layers are free to impose structure.
Protection is based upon password capabilities, address-password pairs. Any holder of a valid capability to an object can access that object. Capabilities can be passed around freely, they are not system objects, but protected by sparsity. Objects do not need to be explicitly attached to a process: if the user deposits their capabilities in a system-maintained data structure, the system will transparently attach the object once it is accessed. This allows execution of programs that have no knowledge of the operation of the protection system.
This is the basic philosophy. A few practical points:
- There are, of course, directory services to map UNIX-style path names onto object addresses. These are, however, user-level services, the system doesn't care about them.
- While all objects are persistent in principle, any new object created is entered into a "kill" list. When the process exits, the kernel deallocates all objects pointed to by this list. The process can at any time remove any object from this list and thus make it truly persistent.
- While all objects are globally visible in principle, objects are not necessarily entered immediately into the appropriate system data structures to make them globally known. This is determined by an object attribute, called "sharable": if this is not set at object creation time, the object is not guaranteed to be globally known. The object's owner can set this bit at any time and thus guarantee global accessibility of the object. Usage of this attribute allows fast allocation and deallocation of objects that are unlikely to be shared (e.g. program stacks).
Etymology
Mungi is an Australian aboriginal word. In one central Australian aboriginal language mungi means "message stick" (something not unlike a capability in operating systems). In the (extinct) language of the aborigines of the Sydney region, mungi means lightning. Pronunciation rules for Mungi (according to the Macquarie "Aboriginal Words" dictionary):- m: similar to English
- u: as in "put" (never like the "u" sound of "but")
- ng: similar to the "ng" of "sing", but not like the "ng" of "finger"
- i: as in "bit" (never like the "i" sound in "bight").