Introduction and Overview
As of Select release 1 Dynamic Areas can provide OS_Heap-like operations which auto-extend and reduce the size of the areas in a similar manner to that of the system areas. Such areas are known as Heap Dynamic Areas, or HeapDAs for short. It is not expected that applications use HeapDAs for their storage - as previously, applications should use application space for application specific data except where this is not feasible.
Modules which need to retain state information may use HeapDAs to handle their memory usage rather than using RMA as previously. If the modules state information does not change regularly - and is reasonably small - then using a HeapDA might be extreme, in which case it would be prudent to continue using RMA. However, where larger, or quite variable data is being stored (such as runtime caches) this may be better held in a HeapDA.
As with any other Dynamic Area, it is important that the total size of the dynamic area is sensibly constrained. Whilst dynamic area sizes should not be unnecessarily restrictive, it is important to use restraint when setting the limits of such areas, just as it is when allocating space in the area itself.
From Kernel 9.36 onward heap areas with no space used will not use the single header page that they previously required. In addition, the manager will not release space if there are fewer than 3 empty pages at the end of the heap. This helps to alleviate cases where data structures are allocated and released at the boundary of a page within the heap, causing repeated area resizes. Whilst it is still possible to trigger this behaviour it is less likely to occur with most structures which the heap is used for. As the page size is 4K, this corresponds to (potentially) 12K excess per heap dynamic area.
Technical Details
Creating a HeapDA
The creation of a Heap Dynamic Area is similar to that of other Dynamic Areas. To indicate that a Dynamic Area is to be controlled by the automatic extension and reduction handlers, bit 14 of the flags should be set on entry to the SWI.
Heap DAs may not :
- Be 'doubly mapped' (bit 6)
- Be resized by the user (bit 7)
- Request specific pages (bit 8)
- Be 'shrinkable' (bit 9)
- Be 'sparse' (bit 10)
- Use area handlers (R6)
SWI Calls
| R0 | = | 14 (HeapDescribe) |
| R1 | = | Dynamic area number to describe |
| R2 | = | Largest free space |
| R3 | = | Total free space |
This SWI is used to describe the space used by the dynamic areas heap in a similar manner to OS_Heap 1.
| R0 | = | 15 (HeapClaim) |
| R1 | = | Dynamic area number to claim from |
| R3 | = | Size to claim |
| R2 | = | Pointer to block |
This SWI is used to claim space from a dynamic area heap in a similar manner to OS_Heap 2.
| R0 | = | 16 (HeapRelease) |
| R1 | = | Dynamic area number to release space from |
| R2 | = | Pointer to block |
This SWI is used to release space previously claimed from a dynamic area heap in a similar manner to OS_Heap 3.
| R0 | = | 17 (HeapResizeBlock) |
| R1 | = | Dynamic area number to resize block in |
| R2 | = | Pointer to block |
| R3 | = | Required size change in bytes |
This SWI is used to resize a previously claimed block in a dynamic area heap in a similar manner to OS_Heap 4.
| R0 | = | 18 (HeapReadBlockSize) |
| R1 | = | Dynamic area number containing the block |
| R2 | = | Pointer to block |
| R3 | = | Size of block |
This SWI is used to determine the space allocated to a previously claimed block in a dynamic area heap, in a similar manner to OS_Heap 6.