-
Each 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 type. The user may define new pool types, and may override the
choice of pool for an access type by specifying Storage_Pool for the
type.
Legality Rules
-
If Storage_Pool is specified for a given access type, Storage_Size shall
not be specified for it.
Static Semantics
-
The following language-defined library package exists:
-
with Ada.Finalization;
with System.Storage_Elements;
package System.Storage_Pools is
pragma Preelaborate(System.Storage_Pools);
-
type Root_Storage_Pool is
abstract new
Ada.Finalization.Limited_Controlled with private;
-
procedure Allocate(
Pool : in out Root_Storage_Pool;
Storage_Address : out Address;
Size_In_Storage_Elements : in Storage_Elements.Storage_Count;
Alignment : in Storage_Elements.Storage_Count) is abstract;
-
procedure Deallocate(
Pool : in out Root_Storage_Pool;
Storage_Address : in Address;
Size_In_Storage_Elements : in Storage_Elements.Storage_Count;
Alignment : in Storage_Elements.Storage_Count) is abstract;
-
function Storage_Size(Pool : Root_Storage_Pool)
return Storage_Elements.Storage_Count is abstract;
-
private
... -- not specified by the language
end System.Storage_Pools;
-
A storage pool type (or pool type) is a descendant of Root_Storage_Pool.
The elements of a storage pool are the objects allocated in the pool by
allocators.
-
For every access subtype S, the following attributes are defined:
-
S'Storage_Pool
Denotes the storage pool of the type of S. The type of this
attribute is Root_Storage_Pool'Class.
-
S'Storage_Size
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
is universal_integer.
-
Storage_Size or Storage_Pool may be specified for a non-derived
access-to-object type via an attribute_definition_clause; the name in a
Storage_Pool clause shall denote a variable.
-
An allocator of type T allocates storage from T's storage pool. If the
storage pool is a user-defined object, then the storage is allocated by
calling Allocate, passing T'Storage_Pool 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. The
Alignment parameter is D'Alignment. The result returned in the
Storage_Address parameter is used by the allocator 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 allocator.
-
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 implementation-defined manner. In 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 pool
type(s).
-
If Storage_Size is specified for an access type, then the Storage_Size
of this pool is at least that requested, and the storage for the pool 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 point of the attribute_definition_clause. If neither
Storage_Pool nor Storage_Size are specified, then the meaning of
Storage_Size is implementation defined.
-
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.
Erroneous Execution
-
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.
Documentation Requirements
-
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.
Implementation Advice
-
An implementation should document any cases in which it dynamically
allocates heap storage for a purpose other than the evaluation of an
allocator.
-
A default (implementation-provided) storage pool for an
access-to-constant type should not have overhead to support deallocation
of individual objects.
-
A storage pool for an anonymous access type should be created at the
point of an allocator for the type, and be reclaimed when the designated
object becomes inaccessible.
NOTES
-
(23) 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
non-trivial 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.
-
(24) The writer of the user-defined allocation and deallocation
procedures, and users of allocators for the associated access type, are
responsible for dealing with any interactions with tasking. In
particular:
-
If the allocators 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, See section C.3 Interrupt Support, the mutual exclusion mechanism has to work properly in that
context.