At the lower level, the common memory is allocated in pages, typically 2, 4 or 8 kilobytes per page. At the higher level, memory is allocated in finer units (paragraphs), typically 16 or 32 bytes per paragraph.
In a common address memory model, a given location in the processors' memory (real or virtual) has the same address in each context (whether it is accessible or not in that context).
Memory is transferred from the common memory pool to a private pool in pages that are linked into the private pool as free space. This free space can then be allocated to an entity.
This two level approach is, normally, invisible to applications as pages are automatically transferred to and from the private pools as required. Applications can, however, control the transfer of pages to and from the free memory pool.
Each entity has its own implicit private memory pool within which memory is allocated. This is referred to as the entity's memory pool. As a job always requires a memory pool, the job's memory pool is set by the task manager up at the same time as the job (it includes the stack, any pre-allocated data areas and, possibly, some or all of the program code).
When an entity is removed, all the allocations in all its memory pools are removed at the same time.
This linkage is critical to the safe handling of entities in a Stella system. When an entity is removed from the system, voluntarily or involuntarily, all the memory that has been allocated to the job needs to be returned to the common pool. This may involve closing IO channels or removing tasks from the handler lists.
When an entity is removed, all of its private pools are scanned for remove linkages. The remove routine appropriate to each allocation is called. It is possible that the remove routine is not able to complete immediately (there may, for example, be queued data that has not yet been sent to an output device), in which case the memory will not be returned but transferred to a pending pool. When it is no longer needed, it is returned to the common memory pool.
This mechanism, which is completely automatic, ensures that the system is self cleaning. There is no need for scavenger tasks, nor any need for jobs to incorporate any cleanup code to return memory or release entities.
In the common memory model, allocations are made directly from the common memory pool. There are no private pools. The operating system calls for managing private pools either return errors or do nothing (depending on the operation).
The use of a common address model makes the whole operating system interface safer, simpler and more efficient than the virtual machine model. Its only disadvantage is that the total virtual memory of all tasks is limited to the addressing range of the processor. It is, therefore, not suitable for implementing virtual memory on a 16 bit address computer (the original design aim of UNIX).
With the Stella virtual memory manager, this mode of operation is possible, but Stella can also offer many of the benefits of virtual memory without either the costs or the hardware.
All memory not permanently allocated can be used as temporary working space. Such temporary working memory may be used by applications for calculation scratch pads, etc., or by device drivers for buffers, caches, etc.