|
Dynamic areas with automatic heap extension
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.
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)
New SWIs
OS_DynamicArea 14
On entry
R0 = 14 (HeapDescribe)
R1 = dynamic area number to describe
On exit
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.
See OS_Heap 1.
OS_DynamicArea 15
On entry
R0 = 15 (HeapClaim)
R1 = dynamic area number to claim from
R3 = size to claim
On exit
R2 = pointer to block
This SWI is used to claim space from a dynamic area heap in a similar manner to OS_Heap 2.
See OS_Heap 2.
OS_DynamicArea 16
On entry
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.
See OS_Heap 3.
OS_DynamicArea 17
On entry
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.
See OS_Heap 4.
OS_DynamicArea 18
On entry
R0 = 18 (HeapReadBlockSize)
R1 = dynamic area number to release space from
R2 = pointer to block
On exit
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.
See OS_Heap 6.
|
![[Select]](../../imgs/seldoc.png)
