13.11 Storage Management

Ramification: By default, the implementation might choose to have a single global storage pool, which is used (by default) by all access types, which might mean that storage is reclaimed automatically only upon partition completion. Alternatively, it might choose to create a new pool at each accessibility level, which might mean that storage is reclaimed for an access type when leaving the appropriate scope. Other schemes are possible. 

Reason: The Storage_Pool determines the Storage_Size; hence it would not make sense to specify both. Note that this rule is simplified by the fact that the aspects in question cannot be specified for derived types, nor for non-first subtypes, so we don't have to worry about whether, say, Storage_Pool on a derived type overrides Storage_Size on the parent type. For the same reason, “specified” means the same thing as “directly specified” here. 

Reason: The Alignment parameter is provided to Deallocate because some allocation strategies require it. If it is not needed, it can be ignored. 

Discussion: In most cases, an element corresponds to a single memory block allocated by Allocate. However, in some cases the implementation may choose to associate more than one memory block with a given pool element. 

Ramification: Storage_Size is also defined for task subtypes and objects — see 13.3.

Storage_Size is not a measure of how much un-allocated space is left in the pool. That is, it includes both allocated and unallocated space. Implementations and users may provide a Storage_Available function for their pools, if so desired. 

Ramification: If the implementation chooses to represent the designated subtype in multiple pieces, one allocator evaluation might result in more than one call upon Allocate. In any case, allocators for the access type obtain all the required storage for an object of the designated type by calling the specified Allocate procedure.

This paragraph was deleted.{AI05-0107-1} Note that the implementation does not turn other exceptions into Storage_Error.

{8652/0111} {AI95-00103-01} If D (the designated type of T) includes subcomponents of other access types, they will be allocated from the storage pools for those types, even if those allocators are executed as part of the allocator of T (as part of the initialization of the object). For instance, an access-to-task type TT may allocate the data structures used to implement the task value from other storage pools. (In particular, the task stack does not necessarily need to be allocated from the storage pool for TT.) 

Discussion: The manner of choosing a storage pool is covered by a Documentation Requirement below, so it is not summarized here. 

Implementation defined: Whether or not the implementation provides user-accessible names for the standard pool type(s).

Ramification: {AI95-00230-01} An anonymous access type has no pool. An access-to-object type defined by a derived_type_definition inherits its pool from its parent type, so all access-to-object types in the same derivation class share the same pool. Hence the “defined by an access_to_object_definition” wording above.

There is no requirement that all storage pools be implemented using a contiguous block of memory (although each allocation returns a pointer to a contiguous block of memory). 

Implementation defined: The meaning of Storage_Size when neither the Storage_Size nor the Storage_Pool is specified for an access type.

Ramification: The Storage_Size function and attribute will return the actual size, rather than the requested size. Comments about rounding up, zero, and negative on task Storage_Size apply here, as well. See also AI83-00557, AI83-00558, and AI83-00608.

The expression in a Storage_Size clause need not be static.

The reclamation happens after the master is finalized. 

Implementation Note: For a pool allocated on the stack, normal stack cut-back can accomplish the reclamation. For a library-level pool, normal partition termination actions can accomplish the reclamation. 

Ramification: For example, an allocator might put the pool element on a finalization list. If the user directly Deallocates it, instead of calling an instance of Unchecked_Deallocation, then the implementation would probably try to finalize the object upon master completion, which would be bad news. Therefore, the implementation should define such situations as erroneous. 

Ramification: This includes during the evaluation of the initializing expression such as an aggregate; this is important if the initializing expression is built in place. We need to allow allocation to be deferred until the size of the object is known. 

Reason: We need this bullet as well as the preceding one in order that exceptions that propagate from such a call to Allocate can be handled within the return statement. We don't want to require the generation of special handling code in this unusual case, as it would add overhead to most return statements of composite types. 

Reason: We allow Allocate to be called during assignment of objects with mutable parts so that mutable objects can be implemented with reallocation on assignment. (Unfortunately, the term "mutable" is only defined in the AARM, so we have to use the long-winded wording shown here.) 

Discussion: Of course, explicit calls to Allocate are also allowed and are not bound by any of the rules found here. 

Ramification: Note that the implementation does not turn other exceptions into Storage_Error.

Reason: This supports objects that are allocated in one or more parts. The second sentence prevents extra or missing calls to Deallocate. 

Ramification: We do not define the relative order of multiple calls used to deallocate the same object — that is, if the allocator allocated two pieces x and y, then an instance of Unchecked_Deallocation might deallocate x and then y, or it might deallocate y and then x. 

Reason: We allow Deallocate to be called anywhere that Allocate is, in order to allow the recovery of storage from failed allocations (that is, those that raise exceptions); from extended return statements that exit via a goto, exit, or locally handled exception; and from objects that are reallocated when they are assigned. In each of these cases, we would have a storage leak if the implementation did not recover the storage (there is no way for the programmer to do it). We do not require such recovery, however, as it could be a serious performance drag on these operations.

Reason: This is “Implementation Advice” because the term “heap storage” is not formally definable; therefore, it is not testable whether the implementation obeys this advice. 

Ramification: Unchecked_Deallocation is not defined for such types. If the access-to-constant type is library-level, then no deallocation (other than at partition completion) will ever be necessary, so if the size needed by an allocator of the type is known at link-time, then the allocation should be performed statically. If, in addition, the initial value of the designated object is known at compile time, the object can be allocated to read-only memory.

Implementation Note: If the Storage_Size for an access type is specified, the storage pool should consist of a contiguous block of memory, possibly allocated on the stack. The pool should contain approximately this number of storage elements. These storage elements should be reserved at the place of the Storage_Size clause, so that allocators cannot raise Storage_Error due to running out of pool space until the appropriate number of storage elements has been used up. This approximate (possibly rounded-up) value should be used as a maximum; the implementation should not increase the size of the pool on the fly. If the Storage_Size for an access type is specified as zero, then the pool should not take up any storage space, and any allocator for the type should raise Storage_Error. 

Ramification: Note that most of this is approximate, and so cannot be (portably) tested. That's why we make it an Implementation Note. There is no particular number of allocations that is guaranteed to succeed, and there is no particular number of allocations that is guaranteed to fail. 

Implementation Note: {AI95-00230-01} For access parameters and access discriminants, Normally the "storage pool" for an anonymous access type would not normally exist as a separate entity. Instead, the designated object of the allocator would be allocated, in the case of an access parameter, as a local aliased variable at the call site, and in the case of an access discriminant, contiguous with the object containing the discriminant. This is similar to the way storage for aggregates is typically managed.

{AI95-00230-01} For other sorts of anonymous access types, this implementation is not possible in general, as the accessibility of the anonymous access type is that of its declaration, while the allocator could be more nested. In this case, a "real" storage pool is required. Note, however, that this storage pool need not support (separate) deallocation, as it is not possible to instantiate Unchecked_Deallocation with an anonymous access type. (If deallocation is needed, the object should be allocated for a named access type and converted.) Thus, deallocation only need happen when the anonymous access type itself goes out of scope; this is similar to the case of an access-to-constant type. 

Ramification: Note that the Storage_Pool attribute denotes an object, rather than a value, which is somewhat unusual for attributes.

The calls to Allocate, Deallocate, and Storage_Size are dispatching calls — this follows from the fact that the actual parameter for Pool is T'Storage_Pool, which is of type Root_Storage_Pool'Class. In many cases (including all cases in which Storage_Pool is not specified), the compiler can determine the tag statically. However, it is possible to construct cases where it cannot.

All access types in the same derivation class share the same pool, whether implementation defined or user defined. This is necessary because we allow type conversions among them (even if they are pool-specific), and we want pool-specific access values to always designate an element of the right pool. 

Implementation Note: If an access type has a standard storage pool, then the implementation doesn't actually have to follow the pool interface described here, since this would be semantically invisible. For example, the allocator could conceivably be implemented with inline code. 

Reason: For example, the implementation is allowed to choose a storage pool for T that takes advantage of the fact that T is of a certain size. If T2 is not of that size, then the above will probably not work. 

User-defined storage pools are new to Ada 95. 

{AI05-0005-1} {AI05-0190-1} Ada 83 originally introduced the had a concept called a “collection,” which is similar to what we call a storage pool. All access types in the same derivation class share shared the same collection. In Ada 95 introduces the storage pool, which is similar in that, all access types in the same derivation class share the same storage pool, but other (unrelated) access types can also share the same storage pool, either by default, or as specified by the user. A collection is was an amorphous grouping collection of objects (mainly used to describe finalization of access types); a storage pool is a more concrete concept — hence the different name.

RM83 states the erroneousness of reading or updating deallocated objects incorrectly by missing various cases. 

{AI95-00435-01} Amendment Correction: Storage pools (and Storage_Size) are not defined for access-to-subprogram types. The original Ada 95 wording defined the attributes, but said nothing about their values. If a program uses attributes Storage_Pool or Storage_Size on an access-to-subprogram type, it will need to be corrected for Ada 2005. That's a good thing, as such a use is a bug — the concepts never were defined for such types. 

{AI95-00161-01} Amendment Correction: Added pragma Preelaborable_Initialization to type Root_Storage_Pool, so that extensions of it can be used to declare default-initialized objects in preelaborated units. 

{8652/0009} {AI95-00137-01} Corrigendum: Added wording to specify that these are representation attributes.

{AI95-00230-01} {AI95-00416-01} Added wording to clarify that an allocator for a coextension nested inside an outer allocator shares the pool with the outer allocator.

{AI05-0051-1} Correction: Added the missing definition of the storage pool of an allocator for an anonymous access result type.

{AI05-0107-1} Correction: Clarified when an implementation is allowed to call Allocate and Deallocate, and the requirements on such calls.

{AI05-0111-3} Added wording to support subpools and refer to the subpool example, see 13.11.4.

{AI05-0116-1} Correction: Added wording to specify that the alignment for an allocator with a class-wide designated type comes from the specific type that is allocated.

{AI05-0193-1} Added wording to allow larger alignments for calls to Allocate made by allocators, up to Max_Alignment_For_Allocation. This eases implementation in some cases.