Contents Index Search Previous Next
13.11 Storage Management
1
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.
2
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
3
If Storage_Pool is specified for a given access
type, Storage_Size shall not be specified for it.
Static Semantics
4
The following language-defined
library package exists:
5
with Ada.Finalization;
with System.Storage_Elements;
package System.Storage_Pools is
pragma Preelaborate(System.Storage_Pools);
6
type Root_Storage_Pool is
abstract new Ada.Finalization.Limited_Controlled with private;
7
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;
8
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;
9
function Storage_Size(Pool : Root_Storage_Pool)
return Storage_Elements.Storage_Count is abstract;
10
private
... -- not specified by the language
end System.Storage_Pools;
11
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.
12/1
For every access
subtype S, the following representation attributes are defined:
13
- S'Storage_Pool
-
Denotes the storage pool of the
type of S. The type of this attribute is Root_Storage_Pool'Class.
14
- 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.
15
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.
16
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.
17
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).
18
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.
19
If Storage_Pool is specified for an access type,
then the specified pool is used.
20
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
21
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
22
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
23
An implementation should document any cases in
which it dynamically allocates heap storage for a purpose other than
the evaluation of an allocator.
24
A default (implementation-provided) storage pool
for an access-to-constant type should not have overhead to support deallocation
of individual objects.
25
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.
26
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.
27
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:
28
- If the allocators
are used in different tasks, they require mutual exclusion.
29
- If they are used
inside protected objects, they cannot block.
30
- If they are used
by interrupt handlers (see C.3, ``Interrupt
Support''), the mutual exclusion mechanism has to work properly in
that context.
31
25 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 (non-abstract) storage
pool type is declared.
Examples
32
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:
33
Pool_Object : Some_Storage_Pool_Type;
34
type T is access Designated;
for T'Storage_Pool use Pool_Object;
35
Another access type
may be added to an existing storage pool, via:
36
for T2'Storage_Pool use T'Storage_Pool;
37
The semantics of this is implementation defined
for a standard storage pool.
38
As usual, a derivative
of Root_Storage_Pool may define additional operations. For example, presuming
that Mark_Release_Pool_Type has two additional operations, Mark and Release,
the following is a possible use:
39/1
type Mark_Release_Pool_Type
(Pool_Size : Storage_Elements.Storage_Count;
Block_Size : Storage_Elements.Storage_Count)
is new Root_Storage_Pool with private;
40
...
41
MR_Pool : Mark_Release_Pool_Type (Pool_Size => 2000,
Block_Size => 100);
42
type Acc is access ...;
for Acc'Storage_Pool use MR_Pool;
...
43
Mark(MR_Pool);
... -- Allocate objects using ``new Designated(...)''.
Release(MR_Pool); -- Reclaim the storage.
Contents Index Search Previous Next Legal