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 :
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.
See 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.
See 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.
See 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.
See OS_Heap 4.
R0 = 18 (HeapReadBlockSize) R1 = dynamic area number to release space from 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.
See OS_Heap 6.
This documentation is copyright 3QD Developments Ltd 2013 and may not be reproduced or published in any form without the copyright holders permission. RISC OS is subject to continuous development and improvement as such all information is reproduced by 3QD Developments Ltd in good faith and is believed to be correct at the time of publication E&OE. 3QD Developments Ltd cannot accept any liability for any loss or damage arising from the use of any information provided as part of the RISC OS Documentation.
HTML document version 1.03 3rd November 2015