13.11 Storage Management
access-to-object type has an associated storage pool. The storage allocated
by an allocator
comes from the pool; instances of Unchecked_Deallocation return storage
to the pool. Several access types can share the same pool.]
[A storage pool is a variable of a type in the class rooted at Root_Storage_Pool,
which is an abstract limited controlled type. By default, the implementation
chooses a standard storage pool
for each access-to-object type.
The user may define new pool types, and may override the choice of pool
for an access-to-object type by specifying Storage_Pool for the type.]
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.
type has an associated storage pool object. The storage for an object
created by an allocator
comes from the storage pool of the type of the allocator
Some storage pools may be partitioned into subpools in order to support
finer-grained storage management.
If Storage_Pool is specified for a given access type,
Storage_Size shall not be specified for it.
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 nonfirst 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.
The following language-defined
library package exists:
with Pure, Nonblocking => False is is
Ada.Finalization.Limited_Controlled with private
Pool : in out
Storage_Address : out
Size_In_Storage_Elements : in
Alignment : in
Storage_Elements.Storage_Count) is abstract
Pool : in out
Storage_Address : in
Size_In_Storage_Elements : in
Alignment : in
Storage_Elements.Storage_Count) is abstract
Storage_Size(Pool : Root_Storage_Pool)
Storage_Elements.Storage_Count is abstract
... -- not specified by the language
Reason: The Alignment parameter is provided
to Deallocate because some allocation strategies require it. If it is
not needed, it can be ignored.
(or pool type
) is a descendant of Root_Storage_Pool.
of a storage pool are the objects allocated in the pool by allocator
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.
Denotes the storage pool of the
type of S. The type of this attribute is Root_Storage_Pool'Class.
Yields the result of calling
Storage_Size(S'Storage_Pool)[, which is intended to be a measure of the
number of storage elements reserved for the pool.] The type of this attribute
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.
or Storage_Pool may be specified for a nonderived access-to-object type
via an attribute_definition_clause
a Storage_Pool clause shall denote a variable.
nominal subtype of the name
specified for Storage_Pool is nonblocking (see 9.5),
then the primitive Allocate, Deallocate, and Storage_Size subprograms
of that type shall be nonblocking. Additionally, if the pool that is
one that supports subpools (see 13.11.4),
the primitive Default_Subpool_for_Pool, Allocate_From_Subpool, and Deallocate_Subpool
subprograms shall be nonblocking.
Aspect Description for Storage_Pool:
Pool of memory from which new will allocate for a given access
Aspect Description for Storage_Size
(access): Sets memory size for allocations for an access type.
We need to be able to describe in contracts (especially
for generic units) whether the operations of a storage pool allow blocking,
and we do that with the nonblocking status of the type. We make the check
when the pool is specified so we can avoid adding a special check to
the declaration of a pool type – we want pool types to follow the
same rules as any other type.
of a type T
that does not support subpools allocates storage from
's storage pool. If the storage pool is a user-defined object,
then the storage is allocated by calling Allocate as described below.
for types that support subpools are described in 13.11.4
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,
for the access type obtain all the required storage for an object of
the designated type by calling the specified Allocate procedure.
(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 allocator
are executed as part of the allocator
(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
If Storage_Pool is not specified
for a type defined by an access_to_object_definition
then the implementation chooses a standard storage pool for it in an
this case, the exception Storage_Error is raised by an allocator
if there is not enough storage. It is implementation defined whether
or not the implementation provides user-accessible names for the standard
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
To be honest:
pragma Default_Storage_Pool (see 13.11.3)
can be used to specify a specific pool (or none at all) to be used with
access types declared in a particular declaration list, rather than a
standard storage pool.
Although there is no language-defined user-accessible
name for the standard pool type(s), the default use of a standard pool
may be indicated using the identifier Standard in the pragma Default_Storage_Pool.
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).
The type(s) of the standard pool(s), and the primitive
Allocate, Deallocate, and Storage_Size subprograms for the standard pool(s)
Reason: We need
to specify that the type is nonblocking so that an instance of Unchecked_Deallocation
is nonblocking if the object type is nonblocking (as the type is used
in the contract). Ada 95 did not declare standard allocation/deallocation
as potentially blocking, so these things can be used in protected types,
and we want that to remain true (with static checking).
If Storage_Size is specified for an access type T, an implementation-defined pool P is used for the type.
The, then the
Storage_Size of P this
is at least that requested, and the storage for P the
is reclaimed when the master containing the declaration of
the access type is left.
If the implementation cannot
satisfy the request, Storage_Error is raised at the freezing
point of type T. The storage pool
P is used only for allocators returning type T or other
access types specified to use T'Storage_Pool. Storage_Error is
raised by an allocator
returning such a type if the storage space of P is exhausted (additional
memory is not allocated). the attribute_definition_clause.
If neither Storage_Pool nor Storage_Size are specified, then the meaning
of Storage_Size is implementation defined. The type of P, and the primitive Allocate, Deallocate, and Storage_Size
subprograms of P are nonblocking.
If neither Storage_Pool nor Storage_Size are specified,
then the meaning of Storage_Size is implementation defined.
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
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
If Storage_Pool is specified for an access type,
then the specified pool is used.
The effect of calling Allocate
and Deallocate for a standard storage pool directly (rather than implicitly
via an allocator
or an instance of Unchecked_Deallocation) is unspecified.
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.
If Storage_Pool is specified
for an access type, then if Allocate can satisfy the request, it should
allocate a contiguous block of memory, and return the address of the
first storage element in Storage_Address. The block should contain Size_In_Storage_Elements
storage elements, and should be aligned according to Alignment. The allocated
storage should not be used for any other purpose while the pool element
remains in existence. If the request cannot be satisfied, then Allocate
should propagate an exception [(such as Storage_Error)]. If Allocate
behaves in any other manner, then the program execution is erroneous.
The Allocate procedure of a user-defined storage pool object P
may be called by the implementation only to allocate storage for a type
whose pool is P
, only at the following points:
During the execution of an allocator
of type T
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
During the execution of a return statement for
a function whose result is built-in-place in the result of an allocator
of type T
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
During the execution of an assignment operation
with a target of an allocated object of type T with a part that
has an unconstrained discriminated subtype with defaults.
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
For each of the calls of Allocate described above, P
'Storage_Pool) is passed as the Pool parameter. The Size_In_Storage_Elements
parameter indicates the number of storage elements to be allocated, and
is no more than D
'Max_Size_In_Storage_Elements, where D
is the designated subtype of T
. The Alignment parameter is a nonzero
integral multiple of D
'Alignment if D
is a specific type,
and otherwise is a nonzero integral multiple of the alignment of the
specific type identified by the tag of the object being created; it is
unspecified if there is no such value. The Alignment parameter is no
more than D
'Max_Alignment_For_Allocation. The result returned
in the Storage_Address parameter is used as the address of the allocated
storage, which is a contiguous block of memory of Size_In_Storage_Elements
storage elements. [Any exception propagated by Allocate is propagated
by the construct that contained the call.]
Ramification: Note that the implementation
does not turn other exceptions into Storage_Error.
“Nonzero integral multiple” of an
alignment includes the alignment value itself, of course. The value is
unspecified if the alignment of the specific type is zero.
The number of calls to Allocate needed to implement an allocator
for any particular type is unspecified.
number of calls to Deallocate needed to implement an instance of Unchecked_Deallocation
) for any particular object
is the same as the number of Allocate calls for that object.
Reason: This supports objects that are
allocated in one or more parts. The second sentence prevents extra or
missing calls to Deallocate.
To be honest:
The number of calls to Deallocate from all sources for an object always
will be the same as the number of calls to Allocate from all sources
for that object. However, in unusual cases, not all of those Deallocate
calls may be made by an instance of Unchecked_Deallocation. Specifically,
in the unusual case of assigning to an object of a mutable variant record
type such that the variant changes, some of the Deallocate calls may
be made by the assignment (as may some of the Allocate calls).
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
, then an instance of Unchecked_Deallocation
might deallocate x
and then y
, or it might deallocate y
and then x
The Deallocate procedure of a user-defined storage pool object P
may be called by the implementation to deallocate storage for a type
whose pool is P
only at the places when an Allocate call
is allowed for P
, during the execution of an instance of Unchecked_Deallocation
, or as part of the finalization of the collection of T
For such a call of Deallocate, P
(equivalent to T
is passed as the Pool parameter. The value of the Storage_Address parameter
for a call to Deallocate is the value returned in the Storage_Address
parameter of the corresponding successful call to Allocate. The values
of the Size_In_Storage_Elements and Alignment parameters are the same
values passed to the corresponding Allocate call. Any exception propagated
by Deallocate is propagated by the construct that contained the call.
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.
An implementation shall document the set of values
that a user-defined Allocate procedure needs to accept for the Alignment
parameter. An implementation shall document how the standard storage
pool is chosen, and how storage is allocated by standard storage pools.
Documentation Requirement: The set of
values that a user-defined Allocate procedure needs to accept for the
Alignment parameter. How the standard storage pool is chosen, and how
storage is allocated by standard storage pools.
An implementation should document any cases in which
it dynamically allocates heap storage for a purpose other than the evaluation
of an allocator
Any cases in which
heap storage is dynamically allocated other than as part of the evaluation
of an allocator
should be documented.
Reason: This is “Implementation
Advice” because the term “heap storage” is not formally
definable; therefore, it is not testable whether the implementation obeys
A default (implementation-provided) storage pool
for an access-to-constant type should not have overhead to support deallocation
of individual objects.
Implementation Advice: A default storage
pool for an access-to-constant type should not have overhead to support
deallocation of individual objects.
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.
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 allocator
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.
The storage pool used for an allocator
of an anonymous access type should be determined as follows:
For other access discriminants and access parameters, the storage pool
should be created at the point of the allocator
and be reclaimed when the allocated object becomes inaccessible;
If the allocator
defines the result of a function with an access result, the storage pool
is determined as though the allocator
were in place of the call of the function. If the call is the operand
of a type conversion, the storage pool is that of the target access type
of the conversion. If the call is itself defining the result of a function
with an access result, this rule is applied recursively;
Otherwise, a default storage pool should be created at the point where
the anonymous access type is elaborated; such a storage pool need not
support deallocation of individual objects.
Usually, a storage
pool for an access discriminant or access parameter should be created
at the point of an allocator
and be reclaimed when the designated object becomes inaccessible. For
other anonymous access types, the pool should be created at the point
where the type is elaborated and need not support deallocation of individual
For access parameters and access discriminants, 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
is typically managed.
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.
27 A user-defined storage pool type can
be obtained by extending the Root_Storage_Pool type, and overriding the
primitive subprograms Allocate, Deallocate, and Storage_Size. A user-defined
storage pool can then be obtained by declaring an object of the type
extension. The user can override Initialize and Finalize if there is
any need for nontrivial initialization and finalization for a user-defined
pool type. For example, Finalize might reclaim blocks of storage that
are allocated separately from the pool object itself.
28 The writer
of the user-defined allocation and deallocation procedures, and users
for the associated access type, are responsible for dealing with any
interactions with tasking. In particular:
If the allocator
are used in different tasks, they require mutual exclusion.
If they are used inside protected
objects, they cannot block.
If they are used by interrupt handlers
”), the mutual exclusion mechanism has to work properly
in that context.
29 The primitives Allocate, Deallocate,
and Storage_Size are declared as abstract (see 3.9.3
and therefore they have to be overridden when a new (nonabstract) storage
pool type is declared.
Ramification: Note that the Storage_Pool
attribute denotes an object, rather than a value, which is somewhat unusual
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.
To associate an access
type with a storage pool object, the user first declares a pool object
of some type derived from Root_Storage_Pool. Then, the user defines its
Storage_Pool attribute, as follows:
Pool_Object : Some_Storage_Pool_Type;
type T is access Designated;
for T'Storage_Pool use Pool_Object;
Another access type
may be added to an existing storage pool, via:
for T2'Storage_Pool use T'Storage_Pool;
The semantics of this is implementation defined for
a standard storage pool.
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.
As usual, a derivative of Root_Storage_Pool may define additional operations.
For example, consider the Mark_Release_Pool_Type defined in 13.11.6
that has two additional operations, Mark and Release, the following is
a possible use:
(Pool_Size : Storage_Elements.Storage_Count)
Subpools.Root_Storage_Pool_With_Subpools with private
-- As defined in package MR_Pool, see 13.11.6
Our_Pool : Mark_Release_Pool_Type (Pool_Size => 2000);
My_Mark : Subpool_Handle MR_Pool.Subpool_Handle
; -- As declared in See 13.11.6
Acc is access
My_Mark := Mark(Our_Pool);
... -- Allocate objects using “new (My_Mark) Designated(...)”.
Release(My_Mark); -- Finalize objects and reclaim storage.
Extensions to Ada 83
User-defined storage pools
are new to Ada 95.
Wording Changes from Ada 83
Ada 83 originally introduced the concept called a “collection,”
which is similar to what we call a storage pool. All access types in
the same derivation class share the same collection. 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 an amorphous grouping 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.
Incompatibilities With Ada 95
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
Extensions to Ada 95
Preelaborable_Initialization to type Root_Storage_Pool, so that extensions
of it can be used to declare default-initialized objects in preelaborated
Wording Changes from Ada 95
Wording Changes from Ada 2005
Added the missing definition of the storage pool of
for an anonymous access result type.
Clarified when an implementation is allowed to call
Allocate and Deallocate, and the requirements on such calls.
Added wording to support subpools and refer to the subpool example, see
Added wording to specify that the alignment for an
with a class-wide designated type comes from the specific type that is
Added wording to allow larger alignments for calls to Allocate made by
up to Max_Alignment_For_Allocation. This eases implementation in some
Extensions to Ada 2012
now has Pure categorization, so it can be mentioned for any package.
Note that this does not allow storage pool objects to be shared between
partitions, as these necessarily must be variables; however, this does
allow a storage pool type to be shared.
Wording Changes from Ada 2012
Corrigendum: Tightened up the description
of the implementation-defined pool used when Storage_Size is specified.
This is not intended to change any implementation.
Specified that the standard pool(s), and the pool(s)
used to implement a specified Storage_Size, are nonblocking. This was
always true (which is why this is not documented as an incompatibility),
but it never was explicitly stated before. In the past, the absence of
wording defining something to be potentially blocking determined if blocking
was not allowed.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe