GB2260005A - Memory manager for an operating system - Google Patents

Abstract

A plurality of address-oriented services, e.g. virtual addressing, garbage collection, are made available to tasks 22, 24, 26 of the operating system. This is achieved, in part, by providing only a single address space for the entire system, by associating independent address- oriented services with sets of addresses that define the address-oriented services that a task is allowed to access, but that do not overlap, and by defining a set of addresses within that address space that a service will be allowed to manage, thereby preventing independent services from attempting to manage the same address in conflicting ways. More specifically, a plurality of domains 10, 12, 14 (each representing a possibly non-contiguous set of addresses of the address space), each corresponds to an address-oriented service, and a plurality of environments 28, 30, 32. Each environment has the ability to control a task's access to a domain so as to take advantage of the address-oriented service offered by that domain. Since these domains do not overlap, an address can only be associated with a single domain. <IMAGE>

Description

MEMORY MANAGER FOR AN OPERATING SYSTEM OF A COMPUTER SYSTEM Field of the Invention The present invention relates generally to the field of operating systems for computer systems, and more particularly to a memory manager for optimizing addressoriented operations performed by an operating system of a fault driven, object-oriented computer system.

Brief Description of the Prior Art The most basic task of an operating system is to give application programs an abstract environment in which to run. One natural, but unfortunate, result of this task when implemented is that application programs are often limited by the operating system's "idea" of the proper environment. If a program design does not conform to this environment, it must be reworked until it can be expressed in the operating system's terms, which is not only inconvenient for the implementor, but may also introduce inefficiency in the program. Problems with environmental restrictions are not only limited to application programs. The operating system itself can often inc'it considerable overhead as a result of måintåining virtual environment features that a particular application does not need.A further problem relates to the provision of multiple address spaces by most operating systems, which typically provide multiple independent address spaces with multiple threads of control in each. Although multiple address spaces are useful for isolating programs from one another, they often isolate them so well that they make it harder for the programs to cooperate. As a result, for example, implementation of shared code libraries is much more difficult with multiple address spaces than without.

Traditional operating systems also have significant limitations in the area of memory management. Over the years, particular hardware has been developed to help provide support for the most common memory management features of such operating systems. In particular, Memory Management Units (MMUs), in addition to providing memory access control, are now almost universally designed to optimize the implementation of demand-paged virtual memory on behalf of the operating system.

An MMU, however, has traditionally been considered an added feature of a CPU, specifically designed to perform a particular address-oriented service, such as virtual memory, rather than as an integral unit upon which other system designs (such as the operating system) are based. Hence, the traditional MMU implementation also limits the manner in which the MMU can control the CPU's access to various addresses, thereby placing all of the burden of determining access to higher level system services on the operating system. In addition, since the operating system generally does not allow access to the lower-level operations that were used to implement such services, those operations cannot be utilized to perform other additional services. And even when some access is allowed, the access is severely constrained.For example, a programmer may have to write code to look like a virtual memory service, even when it isn't, just to obtain access to the appropriate lower-level operations.

As mentioned above, these types of design limitations make it difficult to use the MMU to perform additional tasks, such as concurrent garbage collection, which it should be able to perform, but which cannot be easily implemented using the traditional approach. Although a number of algorithmic solutions have been proposed that would enable an MMU to be able to perform these desired additional tasks, each solution has one or more problems which detract from its overall attractiveness to CPU developers and programmers. For example, Andrew W. Appel, John R. Ellis, and Kai Li, in "Rea!-time Concurrent Collection on Stock Multiprocessors", Proceedings of the SIGPLAN '88 Conference on Programming Language Design and implementation, ACM SIGPLAN Notices, vol. 23(7), June 1988, pp. 11-20, describe an algorithm for implementing concurrent garbage collection using a traditional MMU.As previously noted, one problem with this type of approach, is that the effectiveness of the algorithm is hampered by limitations imposed by the operating system running on the CPU.

A different approach to garbage collection was described by David A. Moon in "Garbage Collection in a Large Lisp System", ACM Symposium on Lisp and Functional Programming (Austin, Texas, August 1984), pp. 239246. Moon proposed utilizing special hardware to support garbage collection in a Lisp-based CPU. This implementation, however, restricts the hardware's application to a single algorithmic solution for garbage collection. In addition, many other algorithms running on the system, which are not related to garbage collection, would not benefit from such a system.

Brief Summary of the Invention A preferred embodiment of the present invention conlprises a memory manager for an operating system of a computer which provides a framework that supports making a plurality of address-oriented services available to tasks of the operating system. This framework is achieved, in part, by providing only a single address space for the entire system, by associating independent address-oriented services with sets of addresses that do not overlap, and by defining a set of addresses within that address space that a service will be allowed to manage, thereby preventing independent services from attempting to manage the same address in conflicting ways.More specifically, the memory manager includes a plurality of domains (each representing a possibly non-contiguous set of addresses of the address space), each of which is associated with an address-oriented service, and a plurality of environments, each of which has the ability to control a task's access to a domain so as to take advantage of the address-oriented service offered by that domain. Since these domains do not overlap, an address can only be associated with a single domain.

Brief Description of the Drawing Fig. 1a is a block diagram illustrating the relationship between domains and environments in accordance with the preferred embodiment of the present invention; Figs. Ib and 1c are block diagrams illustrating the relationship between tasks and the environments of Fig. la; Fig. 2 is flow chart illustrating the operation of the operating system of the preferred embodiment of the present invention in accordance with the elements of the system illustrated in Figs. la, 1b and 1c; Figs. 3a and 3b are block diagrams which illustrate two examples of where a particular environment can be utilized to control a task's access to the address space of a domain in accordance with the preferred embodiment of the present invention.

Fig. 4 is a block diagram illustrating the structural architecture of the memory manager of the operating system of the present invention; and Fig. 5 is a block diagram further illustrating Domain 0 of Fig. 4.

Detailed Description of the Preferred Embodiment 1.0 General Overview of the Present Invention The architecture of a memory manager of an operating system embodying the preferred embodiment of the present invention is described below. Particular attention is directed to the novel elements incorporated into the operating system through the memory manager, called "Domains" and "Environments", which simplify and optimize the handling and performance of address-oriented operations in a fault driven, objectoriented computer system.

Briefly, domains are created by partitioning the system address space into possibly non-contiguous sets of addresses. These address sets do not overlap so that each individual address is located in only one domain. Each domain is also defined by a set of protocols, or controls, that are used to manage the domain's address space, thereby affecting the execution of memory access operations by the CPU. As previously stated, domains and environments will be explained in greater detail below, but, before providing such a detailed description, it is necessary to provide a background of the atmosphere in which domains and environments are utilized.

1.1 General Functions of an Operating System An operating system for a computer system manages a plurality of tasks that embody independently executing programs which run on the CPU. Each program is defined as a set of operations, or tasks, to be performed in some specified order and a set of data that is to be utilized during the performance of the operations. An operating system also provides a set of services that the tasks may utilize during the execution of their programs. A task that utilizes a particular service is said to be a client task of that service. The services provided by an operating system can be implemented as tasks that are activated when a service is requested by some client task. The task responsible for providing a particular service is called the manager task of that service.

There are many different types of operating systems, many of which are particularly designed for operation on a particular CPU. Despite the differences between such systems, there are some common features, including: a memory manager, a task manager, inter-process synchronization, and an input/output manager.

Although each of these features is well known in the art, although maybe not by the provided names, a brief description of each is provided. A memory manager controls the use of memory addresses by application programs and by the operating system. A task manager is operative to create and destroy tasks and to manage the independent execution of tasks by the operating system in memory. Inter-process synchronization refers to the manner in which the exchange of information between tasks is managed.

An input/output manager communicates with and controls the operation of input/output devices that define extensions of the computer system. In particular, the input/output manager supports the notion of secondary storage (disk storage) for use by the operating system. The present invention relates to an improvement of a memory manager of an operating system.

1.2 General Operation of a Memory Mansoement Unit (MMU) In a typical computer system, the central processing unit (CPU) fetches an instruction from memory and executes the operation encoded in the instruction. An operation may consist of one or more address operations, whereby the CPU emits a processor address and an access type that indicates the type of memory operation desired. Normally, the access type is either a read, write, or instruction fetch operation.

A read operation instructs the memory system to read from the location specified by the address and to deliver the retrieved data to the CPU. A write operation provides data (in addition to the address and access type) to be written to the specified address.

An instruction fetch operation typically functions identically to the read operation, only the access type, in this case, is used to indicate that the retrieved data will be used as an instruction. It should be noted that not all CPU designs differentiate between read operations and instruction fetch operations. By convention, however, all operations perform at least one address operation: that operation being the fetching of the instruction itself.

Address operations in most traditional computer systems are managed by an MMU. The MMU typically handles virtual addressing and it controls physical memory access by the CPU. The MMU sometimes has the additional responsibility of controlling access to various portions of memory in order to provide separation and protection of address spaces. The MMU translates processor addresses (hereafter called "addresses" or'virtual addresses") provided by the CPU into physical (memory) addresses that correspond to storage locations in the computer system's primary memory, Random Access Memory (RAM). These addresses are conventionally translated into physical addresses through use of a look-up table (called a "page table"), which can often be quite large.Since address translation by reference to a translation table stored in RAM can impose a generally unacceptable processing overnead, it is common practice to provide a high-speed cache of recently used address translations. Such a cache is commonly referred to as a translation lookaside buffer (TLB). The TLB stores a set of the most recently used virtual addresses, thereby making it possible to perform address translations in a single machine cycle.

If a requested virtual address does not have a translation in the TLB to a physical address, the translation must be retrieved from the page table in RAM, with the translation then being stored in the TLB. Retrieval of the translation from main memory is initiated by the detection of the absence of an appropriate TLB entry. If the appropriate translation information is not found in the page table, a "translation fault is generated by the MMU. If appropriate translation information is found in the page table, it is loaded into the TLB and the memory access operation continues.

In normal MMU designs, the TLB also contains access permissions for each virtual address. Hence, if the table entry is valid, the access permissions in the translation entry are checked against the CPU access type. If the access type is allowed, the memory access is performed with the physical address provided by the TLB (assuming no other faults are raised, as will be explained later). If the access type is not allowed, a "permission fault" is generated for transmission to the CPU.

The purpose of a fault, such as the translation fault, is to notify the CPU of exceptional conditions that have occurred during the execution of an instruction. The transmission of a fault from the MMU to the CPU causes cancellation of the operation currently in progress and execution (often through a vector table) of a fault handling routine by the CPU. When the operation is canceled, the CPU typically returns to the state it was in prior to the attempted execution of the operation that caused the fault.

The fault handling routine determines the cause of the fault and acts on that cause.

Unless the fault was a non recoverable fault, the CPU then continues execution of operations starting at the point of cancellation. In some computer systems, many faults may be combined into a single CPU fault. The particular fault which has occurred is therefore determined by examining a Fault Status Register. Faults may also be prioritized in such a way that certain faults mask (or inhibit) others. A Fault Dispatch Unit gathers the various fault sources, maintains the Fault Status Register, and asserts a single fault to the CPU.

2.0 Memory Address Management in the Operating System of the Present Invention The operating system of the present invention provides a flexible and general framework that allows users (system designers) to build desired features in order to control memory access. Although the operating system contains many cooperating tasks, some of the most significant, at least in terms of the present invention, are the address-oriented services, such as garbage collected heaps, persistent object stores, and virtual memory. These service are presented to their clients as special regions of memory, referred to above as "domains", that behave in particular ways and that keep the overhead of the operating system relatively low, thereby giving the user more freedom to trade features for hardware costs.This form of memory address management in an operating system is particularly conducive to the implementation of address-oriented services, especially since it does not require a special MMU for the user to take advantage of the services. This concept of memory address management, which underlies the operating system, is further described below.

2.1 Tasks. Environments and Domains The memory manager of the operating system of the present invention is designed to provide a framework that supports the operation of multiple addressoriented services. This framework is achieved, in part, by providing only a single address space for the entire system, by associating independent services with sets of addresses that define the services that a task is allowed to access, but that do not overlap, and by defining a set of addresses within that address space that a service will be allowed to manage, thereby preventing independent services from attempting to manage the same address in conflicting ways. More specifically, the address space of the system is partitioned into a set of domains, as described above, representing possibly non-contiguous sets of addresses.Since these domains do not overlap, an address can only be associated with a single domain. The memory manager also utilizes environments (as defined herein), which control a task's access to the address space, and therefore the associated services, of one or more domains. Hence, with reference now to Figures la, 1b and Ic, the operating system's function of providing a set of services is achieved through the memory manager by associating a service with a particular domain (such as Domain1 of domains 10 through 14 of Figure 1a) which a task (such as Task0 of tasks 16 through 26 of Figures 1b and 1c) has access to through an environment (such as Environment0 of environments 28 and 32).

Although domains will be further explained below, it should also be noted at this point that each of these domains has an associated task, called its manager, which is in charge of providing the services associated with that particular domain. Domains are also associated with sets of controls which affect the execution of memory access operations, including virtual-to-physical translations and access permissions.

The functions of environments and domains in a computer system can be more fully described with reference now to Figures 2 and 3. The block diagram of Figure 2 further illustrates the functional characteristics of the tasks, environments and domains depicted in Figure 1. In step 34, an attempt is made to determine the proper environment for a task. Assuming that such an environment can be determined, an issue which will be further addressed below, the environment will then proceed to ask, in step 36, whether that task is accessing a domain which is part of that environment. If so, the operation of that task is allowed to be performed, step 38. Otherwise, the operation of that task is inhibited, step 40.

Figures 3a and 3b illustrate two examples of where a particular environment can be utilized to control a task's access to the address space of a domain in accordance with the present invention and in accordance with Figures 1 and 2. In Figure 3a, the two tasks 42 and 44 represent the many tasks embodied by the programming language C, which would be running on the operating system of the present invention. These tasks would be part of the C runtime environment 46, which controls the access of these tasks to the address space of various domains, such as the stack domain 48 and the virtual memory domain 50, as will be further explained below.

In Figure 3b, the two tasks 52 and 54 represent the many tasks embodied by a dynamic language programming language, such as Lisp, which would run on the operating system of the present invention. As in the situation illustrated in Figure 3a, these tasks would be part of the dynamic language runtime environment 56, which controls the access of these tasks to the address space of various domains, such as the garbage collected heap domain 58 and the persistent object store domain 60, which are additional address-oriented services that are further described below.

2.2 Address Management Tools In terms of the present invention, there are two primary types of address management tools: constraints and mappings. The following description of these tools should further assist to define the atmosphere in which domains are utilized and how some address-oriented services generally described above operate in this atmosphere. But before describing these tools, it is also necessary to describe faults, at least in the context of a fault-driven computer system, with respect to the operating system of the present invention. A fault is an event generated by the execution of an instruction. This execution process will halt and signal a fault if the appropriate conditions are met.The signal is usually passed to the manager of a domain, as determined by the type of fault and the operands of the instruction. Depending on the situation, the instruction may be restarted after the fault is handled.

2.2.1 Constraints Constraints place restrictions on allowable address operations.

Constraints include global constraints, access control barriers, and control-flow barriers. Global constraints accept one or more domain specifiers, as further described below, and information about the access type of an address operation.

Global constraints then deliver a fault upon detection of an access violation.

A barrier is a restriction of read access, a restriction of write access, a restriction of the flow of addresses, or a restriction of the flow of control between domains.

Violation of a barrier causes a fault to be signaled, which in turn causes some action to be taken. More specifically, there are three kinds of barriers: (i) A read barrier restricts tasks from reading from a location; (ii) A write barrier restricts tasks from writing addresses located in one domain into another domain; (iii) A control-flow barrier restricts program counter movement between domains. Because write barriers and control-flow barriers regulate the relations between domains they are called crossdomain restrictions.

A write barrier only applies when the data being written is an address. In order to implement write barriers, the system must be able to distinguish pointer data from non-pointer data, which is a common requirement of address-oriented services, such as garbage collectors.

2.2.2 Manoioas During instruction execution, various translations are performed on addresses. Mappings define these translations. Mappings work in conjunction with the domain classifier, as will be further described below. If a translation reveals a constraint, then the constraint is compared against the type of address operation. If the translation is missing, a translation fault is generated.

The most important mappings are the virtual address to physical address mappings, which are used to translate virtual addresses into physical addresses, and the virtual address to permissions mappings, which are used to determine the types of access allowed to an address.

2.3 Address-Oriented Services Many different types of address-oriented services, some of which are yet to be conceived, could be implemented through use of the present invention. Although many of these services are generally known in the art, they are often described by prior art references in confusing or conflicting terms. Hence, in order to clarify the meaning of these services with respect to the present invention, some addressoriented services, presented in terms of the model of address management of the present invention, are described below.

2.3.1 Virtual Memory A virtual memory service allows a program being executed by an operating system to effectively use more memory as RAM than there is actual physical RAM available in the computer system. Virtual memory is actually a portion of memory in a mass-storage device, such as a hard-disk drive. Hence, virtual memory is only virtual in terms of physical RAM. Clients of the virtual memory service, however, use this virtual memory as though it were all physically available RAM. The virtual address space is created by "swapping out" part of the data in RAM to the mass-storage device.

This virtual memory is conventionally organized into a plurality of pages, each comprising a prescribed number of bytes, which are correlated with specific locations in RAM. The virtual memory service operates by intercepting a client's attempt to access pages of virtual memory that have been swapped out to disk, swapping the pages back into RAM (and possibly swapping some pages out of RAM if there is no room left), and then allowing the client to proceed.

Pages of virtual memory that have been mapped to pages of physical memory are referred to as "valid" pages, while pages of virtual memory that have no associated physical memory, and are either unallocated or are swapped out to disk, are referred to as "invalid" pages. When clients attempt to access invalid pages, the virtual memory service is typically notified by the MMU, which issues a fault called a "translation fault".

Upon notification of a translation fault, the virtual memory service maps the physical RAM into pages, fills the pages of RAM with the appropriate data read from the storage device, and releases the pages so the clients can access them freely. When physical RAM becomes scarce, the virtual memory service needs to pick some valid pages and swap them out, once again preventing clients from accessing those pages.

In terms of the present invention, a simple paged virtual memory service works by manipulating only the address mapping for its domain. It maps the available physical memory to the valid (swapped-in) virtual pages in its domain, and unmaps the virtual pages that are swapped out. Such a simple implementation will perform more disk writes than necessary, since a page that has not been changed since it was swapped in need not be written to disk when it is swapped out. By giving clients readonly permission to a newly swapped-in page, the service can be notified when a client writes to it. That page can then be marked "dirty" and assigned read-write permission.

Only dirty pages need to be written to disk. Thus, a more sophisticated virtual memory service will manipulate the permission mapping of its domain as well as the address mapping.

2.3.2 Garbage Collectors In terms of a garbage collector service, garbage is storage that is no longer accessible by "legal" language operations. A garbage collector service finds garbage and makes that storage available for use by the operating system. Many garbage collector services do this by finding all storage objects that are not garbage and eliminating the rest. These "non-garbage" objects are found by recursively following all pointers contained in the storage objects of the system, starting at a set of root objects, which would include global variables and the processor state of all tasks.

There are a number of different types of garbage collector services, three of which are described below.

2.3.2.1 Stop-and-Copy Garbage Collector In accordance with the stop-and-copy garbage collector service, memory is divided into two regions, called "from-space" and "to-space". During normal execution, objects reside in to-space, and from-space is not used. When to-space is exhausted (or nearly so), processing halts. The identities of the spaces are then exchanged (flipped) so that from-space becomes to-space, and vice versa. The root objects are then copied into to-space, and the objects in to-space are then scanned for pointers into from-space. When such a pointer is found, the referenced object in fromspace is copied to the end of to-space, where it will eventually be scanned, and the pointer in the object being scanned is updated to refer to the referenced object's new location.A forwarding pointer is left in place of each copied object, so later references to the object can be updated.

The above process has the effect of copying all of the reachable objects into tospace, and updating all of the pointers in the objects to refer to the locations of the copies. When all of the reachable objects have been copied, any objects left behind in from-space are considered garbage, from-space is reclaimed, processing is resumed, and the garbage collection service is repeated.

2.3.2.2 Concurrent Collector The concurrent garbage collector service is like the stop-and-copy garbage collector service, except that: (a) it does not require the client to stop running while garbage collection occurs; and (b) it enforces a requirement that the client not be allowed to see addresses in from-space, and therefore cannot tell if garbage collection is incomplete. The restriction on clients' ability to see (read) addresses in from-space is a read barrier, which is implemented by manipulating the address-to-permission mapping of its domain. After the flip, all memory that could contain addresses in fromspace is protected from client access by.turning off the clients' read access; then the copying process begins. When a page in to-space has been scanned, all the pointers in that page have been translated into to-space pointers. This means that the client can access that page in memory without seeing from-space addresses; so the protection on that page can be removed. Hence, when a client attempts to access a protected page, the access is intercepted and the collector is signaled. The collector immediately proceeds to scan and translates that page, removes its protection, and allows the client to proceed.

2.3.2.3 Genemfion-Scavenoing Collector Most objects become garbage very soon after being allocated, if at all, so an old object is less likely to become garbage than a new object. Generationscavenging collectors exploit this phenomenon by concentrating their effort on younger objects. Memory is divided into multiple regions called generations, which are ordered by age and can be independently scavenged (garbage-collected).

Objects are created in the youngest generation. When an object has survived several scavenges, it is moved to the next-older generation. Older generations are scavenged less frequently than newer generations.

To scavenge generations independently, the collector must be able to determine which objects in a generation are referenced from other generations, since these objects must not be collected, even though there may not be any references to these objects within their own generation. To do this, the collector needs to keep track of pointers from older generations into newer ones, or in other words, detect addresses leaving their "home" generation. This is accomplished by constructing an address-flow barrier, wherein one domain is assigned to each generation, and operations that attempt to write an address.in one domain into a location in another domain are intercepted.It should also be noted, that since it is uncommon for an object to reference younger objects, it is possible to only record references from older generations to newer generations, which can be done with little overhead. Because references from younger to newer objects are not remembered, it is necessary, when scavenging a generation, to scavenge all younger generations at the same time, which doesn't require much additional effort.

2.3.3 Persistent Obiect Store For purposes of the present invention, a persistent object store means a collection of objects kept on a mass-storage device. Although the addresses of these objects may not be in the same format as addresses in memory (for example, store addresses may be 64 bits long and memory addresses only 32 bits), and these objects may contain pointers in this altered format, clients will still access these objects as though they were simply present in memory in the usual format with pointers in the format of memory addresses. When the store is opened, the root objects of the store are read into memory and translated to memory format. Virtual address space is allocated for the objects referenced by the root objects, but no physical memory is mapped into it, so the service is notified whenever clients attempt to read or write to this space.Upon notification, the service reads the appropriate object into memory and translates it, allocating space for the objects referenced by the object as before, and the process repeats.

A store of the type described above contains features of all of the above services. For example, it prevents clients from seeing persistent addresses by translating persistent objects on demand. In this way, it is similar to a concurrent garbage collector preventing its clients from seeing from-space addresses. The store manipulates the permission mapping of its domain to intercept reads and writes to untranslated pages. The store is also similar to a virtual memory service in that it dynamically assigns physical memory to the parts of the store that are resident in memory. It manipulates the address mapping of its domain to assign physical memory where it is needed. And, like the generation scavenging garbage collector, the store must detect cross-domain address operations.In particular, the store needs to know about pointers from persistent objects to transient objects so it can make those transient objects persistent, which is an address-flow barrier.

3.0 Formal Model of Memory Manager of the Operating System With reference now to Figures 4 and 5, block diagrams illustrating the operation of the memory manager of the operating system of the present invention are shown.

Although the schematic nature of Figures 4 and 5 could be interpreted to imply that the present invention is preferably implemented in hardware, the blocks of Figures 4 and 5 are intended to represent structural elements of the present invention as preferably implemented in software. Naturally, the present invention could also be implemented in hardware, or a combination of hardware and software, provided a schematic flow similar to that illustrated was followed. But, since operating systems are typically implemented in software, it is therefore preferable to implement the memory manager of such an operating system in software as well. Regardless of the method of implementation, however, Figures 4 and 5 work well to illustrate the concepts of domains and environments as used within a memory manager of an operating system.

With reference now to Figure 4, during the execution of a task 100, a memory operation is performed which provides the following informational signals to the operating system: a specification of the environment 102 that the task is running in; the target address 104, the access type 106 and data 108, as necessary, associated with the memory operation. That information is then used by the memory manager of the operating system to control the performance of the memory operation. The domain classifier 110 receives the target address 104 and determines the domain where the target address 104 resides. There can be a large number of domains, for example, domain0 112, domain1 114 through domainn 116, comprise the domains of the operating system.If the domain classifier 110 cannot determine the domain where the target address 104 resides, a domain fault signal 118 is generated by the domain classifier 110 and sent to the fault dispatch 120 for the task 100. Fault dispatch 120 will be further explained below. If a domain can be found for the target address 104, a domain specifier signal 122 is generated by the domain classifier 110 and conveyed to the environment controller 124 and the domain selector 126.

The environment controller 124 receives the environment specifier 102 from task 100, and together with the domain specifier 122, determines if the domain indicated by the domain specifier 122 is part of the task's environment. If the domain is not part of the task's environment, a domain access violation signal 128 is generated and sent to fault dispatch 120. Otherwise, an authorization signal 130 is generated and sent to domain selector 126. After being so authorized, domain selector 126 uses domain specifier 122 to enable the domain specified by the domain classifier 110 via one of the plurality of enable lines 132.

Each of the domains 112 through 116 receives the environment specifier 102, the target address 104, and the access type 106 from the executing task 100. Each domain has a separate enable 132 line, and only the domain indicated by domain specifier 122 is actually provided with an enable signal over enable 132. After being enabled, a domain, such as domain 112, determines if the desired memory operation is to be performed. If the memory operation is to be performed, the domain generates the physical address 134 corresponding to the target virtual address 104, along with a memory operation enable signal 136. After passing through OR gate 137, enable signal 136 is conveyed to memory 138, which also receives the access type 106 of the task 100.In addition, depending on the access type 106, data 108 is either received in memory 138 from task 100 or output to the task 100 from memory 138. If the domain 112 determines that the memory operation is not to be performed, the domain 112 generates an access violation signal 140, which after passing through OR gate 142, is conveyed to fault dispatch 120. If fault dispatch 120 receives either a domain fault 118, a domain access violation 128, or an access violation 140, it issues a fault signal 144 to task 100 halting the execution of the task 100.

It should also be noted that in accordance with the present invention, each domain corresponds to an overall predetermined set of rules for the control of the performance of a memory operation. To the extent that a domain performs a different address-oriented service from another domain, the rules defining that service are different from the rules defining other services. These types of rules are domaindependent rules. To the extent that a domain performs the same functions as any other domain, such as virtual to physical address translation, the rules which control the performance of the memory operation are the same for each domain. These rules are domain-independent rules. With reference now to Figure 5, the specific operation of a domain, and the specific implementation of the aforementioned rules, will be further illustrated.As specified above, with reference to Figure 4, a domain, such as domain 112, receives environment specifier 102, target address 104, access type 106, and enable 132. After processing this infqrmation in accordance with the present invention, the domain then either emits the physical address 134 and the enable 136 to memory 138 which will enable the requested memory operation to be performed, or the access violation 140 to fault dispatch 120 to prohibit the requested memory operation, provided that the domain 112 is enabled to perform such operations. If the domain 112 is enabled, the address map 145 either translates the target address 104 into the physical address 134, or generates an address translation fault 146. Address translation fault 146 is generated if no physical address is found to correspond to the target address 104.If an address translation fault 146 is generated, it is sent to domain fault controller 148.

The permission map 150 takes the target address 104 and the environment specifier 102 and maps the intersection into a permission, which is generated as access permission signal 152. If there is no permission at the intersection of the target address 104 and the environment specifier 102, a permission translation fault signal 154 is generated. If the permission mapping was successful, the permission 152 is received by access controller 155, along with the access type 106 and enable 132.

Access controller 155 then generates an access denial signal 156 if the access type 106 is not allowed by the domain 112.

Access denial 156 is conveyed to the domain's fault controller 148. Fault controller 148 monitors the various types of fault conditions and emits an inhibit signal 160 to the manager task 162 if any of the fault conditions are present. Upon receipt of inhibit 160, which specifies the type of fault that occured, the manager task 162 of domain 112 will typically generate access violation 140, unless the manager task 162 determines that it could make modifications to the address map 145 and/or the permission map 150 via map modification signal 164 that would allow the memory operation to be performed. If the managertask 162 does not receive inhibit 1-60, the memory operation specified by the task 100 is allowed to be performed, via issuance of enable 136 to memory 138.

Although the present invention has been described with reference to Figs. 1 through 5 and with emphasis on a particularly preferred embodiment, it should be understood that the figures are for illustration only and should not be taken as limitations upon the invention. It is contemplated that many changes and modifications may be made by one of ordinary skill in the art to the elements, process and arrangement of steps of the process of the invention without departing from the spirit and scope of the invention as disclosed above.

Claims (14)

1. A memory manager for an operating system of a computer for making an address-oriented service available to tasks of the operating system, the computer having a processor and a memory, each of said tasks including a sequence of operations operative to be performed by the processor, each of said operations specifying one or more memory operations, each of said memory operations specifying a processor address, the processor having a memory management unit for translating processor addresses into memory address and performing said memory operations, the memory manager comprising: means for providing an extensible set of address-oriented services to said tasks; and means for regulating which of said address-oriented services of said extensible set are available to a task.

2. A memory manager for an operating system as described in claim 1, wherein said providing means includes: a plurality of domains, each of said domains corresponding to an addressoriented service, each of said domains having means for specifying which of said memory operations can be performed by said memory management unit and how said memory operations are to be performed by said memory management unit, each of said domains further having a domain manager task for modifying said specifying means of said domain when said domain prohibits a memory operation from being performed in order to allow a prohibited memory operation to be performed by said memory management unit; and means for determining which of said domains corresponds to an operation of said task.

3. A memory manager for an operating system as described in claim 2, wherein each of said domains defines a set of addresses associated with said addressoriented service, wherein each address of said set of addresses is associated with a single domain.

4. A memory manager for an operating system as described in claim 3, wherein said determining means includes a domain classifier for associating an address of one of said address operations with one of said domains.

5. A memory manager for an operating system as described in claim 2, wherein said regulating means includes: one or more environments, each of said environments corresponding to a set of said domains; and means for associating said task with one of said environments, whereby said task is restricted to accessing only said set of said domains.

6. A memory manager for an operating system as described in claim 5, wherein each of said domains defines a set of addresses associated with said addressoriented service, wherein each address of said set of addresses is associated-with a single domain.

7. A memory manager for an operating system as described in claim 6, wherein said determining means includes a domain classifier for associating an address of one of said address operations with one of said domains.

8. A memory manager for an operating system as described in claim 2, wherein said specifying means includes: a permission mapping means for specifying which of said memory operations can be performed by said memory management unit; and an address mapping means for specifying how said memory operations are to be performed by said memory management unit, said address mapping means having means for performing a processor address to memory address translation in order to specify how said memory operations are to be performed by said memory management unit.

9. A memory manager for an operating system as described in claim 1, wherein said regulating means includes: one or more environments, each of said environments corresponding to a subset of said extensible set of address-oriented services; and means for associating said task with one of said environments, whereby said task is restricted to accessing only said subset of said extensible set of addressoriented services.

10. A memory manager for an operating system of a computer for making a plurality of address-oriented services available to tasks of the operating system, the memory manager comprising: a plurality of domains, each of said domains corresponding to an addressoriented service; and one or more environments, each of said environments having means for controlling which of said tasks is allowed access to said domains.

11. A memory manager for an operating system as described in claim 10, wherein each of said domains defines a set of addresses associated with said addressoriented service, wherein each address of said set of addresses is associated with a single domain.

12. A memory manager for an operating system as described in claim 11, wherein each of said tasks includes a sequence of operations operative to be performed by said computer, each of said operations specifying one or more memory operations, said memory manager further comprising a domain classifier for associating an address of one of said address operations with one of said domains.

13. A memory manager for an operating system as described in claim 10, wherein said computer includes a memory management unit for translating processor addresses into memory address and performing said memory operations, and wherein each of said domains includes: a permission mapping means for specifying which of said memory operations can be performed by said memory management unit; and an address mapping means for specifying how said memory operations are to be performed by said memory management unit, said address mapping means having means for performing a processor address to memory address translation in order to specify how said memory operations are to be performed by said memory management unit.

14. A memory manager for an operating system as described in claim 10, wherein each of said tasks includes a sequence of operations operative to be performed by said computer, each of said operations specifying one or more memory operations, wherein said computer includes a memory management unit for translating processor addresses into memory address and performing said memory operations, and wherein each of said domains includes: a permission mapping means for specifying which of said memory operations can be performed by said memory management unit; and an address mapping means for specifying how said memory operations are to be performed by said memory management unit, said address mapping means having means for performing a processor address to memory address translation in order to specify how said memory operations are to be performed by said memory management unit.