|
Previous: TABLE OF CONTENTS |
TOC: Table of Contents |
Index: All Documents |
Next: memory.library/NewAdrSpaceA |
| Purpose: |
| The memory.library provides functions for memory allocation and deallocation that are superior to those of the exec.library. The functions of this library provide so called "virtual memory" by using the mmu.library, memory that can be swapped to disk transparently to the application. Hence, applications will be usually able to allocate more memory than physically available. Certain access restrictions arise for memory allocated by the memory.library. First, you can't access it in Forbid() or Disable() state. Trying to do so may certainly cause a fatal "Guru" of the Bus-Error type. The memory.library does further not allow you to allocate or release memory while in Forbid() or Disable() state, so beware! Second, virtual memory cannot be shared amongst different pools. You must explicitly attach the tasks that should be able to access memory from a given pool. Thus, you can't use this kind of memory for keeping Os structures since they may be passed to different tasks for further processing. Use the classic AllocMem() for this purpose, it will give you "shared memory" or "shareable memory". Third, you MAY NOT access virtual memory in a situation where file I/O would be impossible. That is, DO NOT access this mem while: - disabling the filing system of the swap partition if you're using a file based swapping mechanism - making the swapping exec device unaccessible - taking over the hardware The mmu.library will try to detect such situations and will throw a guru whenever possible. However, if it is not, these situations will result in a dead-lock! Keep care! OBJECTS: Two new objects are introduced by the memory library: The "AddressSpace" and the "VMPool". Both objects have no documented structure and should not be touched by your application directly. Similarly to the MMUContext of the mmu.library, these two should be understood as "magic cookies" that have to be passed into the functions of the memory.library. The AddressSpace is an extension of the "MMUContext" of the mmu.library; it defines a "meaning" to addresses for all tasks that are part of a certain address space. Hence, a "Task" in the exec sense should be understood as a "thread" in the sense of Un*x, and an "AddressSpace" as the analogue of a "process" as all tasks that are part of an "AddressSpace" share common addresses. Tasks must enter and leave address spaces explicitly by functions provided by this library. Each MMUContext can hold *at most one* AddressSpace, not more. In case you want to build a new address space, you are hence strongly encouraged to build a private MMUContext of the "shared" type, see the mmu.library documentation for details. Do not try to attach an address space to the public MMUContext. A VMPool can be understood as the analogue of the memory pools of the exec.library. Each AddressSpace can hold as many pools as you need, each of them with a well-defined set of caching modes and memory property flags. You may even define a private swapping mechanism on a per-pool basis. A VMPool need not to carry memory that is available for allocation by means of AllocVMemory() resp. FreeVMemory(). A VMPool can also hold the image of a file which is, as a whole, mirrored in memory. The file contents can then be altered simply by working on the image in memory, without even requiring to hold the file in memory completely. Swapping will happen automatically and completely transparent to your application. This is similar to the Un*x mmap() feature. The restriction that virtual memory cannot be accessed during Forbid() or Disable() can be weakened somewhat by the LockMemory/UnlockMemory resp. HoldMemory/UnholdMemory functions. Where the first pair guarantees that the addressed memory cannot be flushed out and hence remains valid within Forbid()/Disable(), the second pair even returns a continuous *physical* memory block that can be transfered to and from disk using traditional I/O mechanisms. Note that LockMemory() does not allow this as a "logical" memory block may be fragmentated into several physical memory blocks that do not form a continuous memory block by their physical addresses. As both functions require the complete memory block to fit into the system main memory, you are encouraged to hold locks as short as possible. This kind of "virtual memory" is of course some kind of a "poor man's solution" for implementing virtual memory. No exec function will be patched and old programs will continue to work without any change. The library is of course of limited or no use at all for old programs since it doesn't redirect standard memory allocation functions to their "virtual" counterparts. Thus, this is a very "conservative" approach to overcome this limitation of AmigaOs. A special "VMM/GigaMem" is planned to be made available that uses the functions of this library to provide virtual memory to every task. However, since this CAN'T be fully compatible to old programs and may, therefore, cause some compatibility problems. It should be up to the user if she/he likes to install a patch like this or not, but it should NOT the way how virtual memory enters AmigaOs, at least not now. |