TABLE OF CONTENTS
Table of Contents
| 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
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!
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
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
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.