Stella Memory Management

 

Standard Memory Model

All standard Stella memory managers use a two-level real memory model with common addresses.

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 Pools

The standard Stella memory managers have a two-level approach to memory allocation: a common memory pool and many private memory pools.

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).

Additional Private Memory Pools

A job or entity can also define additional private memory pools. Partitioning the memory allocation in this way has a number of benefits.

When an entity is removed, all the allocations in all its memory pools are removed at the same time.

Remove Linkages

Each allocation in a memory pool may include a "linkage" that is used to provide a "remove" routine for that particular allocation (this is similar to an object destructor).

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.

Common memory model

The standard memory model has been designed so that it is directly compatible (at the applications interface level) with the Stella common memory model which is more suitable for small or very small systems (less than a megabyte of RAM).

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).

Virtual memory model

The standard memory model is also directly compatible with the Stella virtual memory model which uses a common address model. In a common address model, the address of a given byte in the virtual memory space is the same in all contexts, while in the virtual machine model a given address refers to a different virtual address in each context.

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).

Temporary Memory

Modern computer systems usually have a very large excess of real memory. Using a classic virtual memory operating system, this excess memory is soon eaten up by enormous quantities of code that will never be used, fixed size buffers ôjust in caseö and masses of data, which, when required, could be retrieved from the original file just as quickly and easily as recovering it from a swap file.

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.  

  Back to table of contents.


Copyright (c) 1997 Tony Tebby.