13.11.5 Subpool Reclamation
A subpool may be explicitly deallocated using Unchecked_Deallocate_Subpool.
The following language-defined library procedure exists:
(Subpool : in out
with Global => in out all
The Global specification for this routine needs
to account for the dispatching call to the user-defined Deallocate_Subpool
routine. We can't use the Dispatching aspect (see H.7.1)
as that requires a statically named object (we have a function call here),
so we have to use in out all in order to allow the user-defined
subprogram to do anything it needs to do.
If Subpool is null
, a call on Unchecked_Deallocate_Subpool has
no effect. Otherwise, the subpool is finalized, and Subpool is set to
The subpool no longer belongs to any pool;
Any of the objects allocated from the subpool that still exist are finalized
in an arbitrary order;
All of the objects allocated from the subpool cease
The following [dispatching] call is then made:
The subpool ceases to belong to any pool.
Finalization of a Root_Storage_Pool_With_Subpools object finalizes all
subpools that belong to that pool that have not yet been finalized.
Discussion: There is no need to call
Unchecked_Deallocation on an object allocated in a subpool. Such objects
are deallocated all at once, when Unchecked_Deallocate_Subpool is called.
If Unchecked_Deallocation is called, the object
is finalized, and then Deallocate is called on the Pool, which typically
will do nothing. If it wants to free memory, it will need some way to
get from the address of the object to the subpool.
There is no Deallocate_From_Subpool. There is
no efficient way for the implementation to determine the subpool for
an arbitrary object, and if the pool implementer can determine that,
they can use that as part of the implementation of Deallocate.
If Unchecked_Deallocation is not called (the
usual case), the object will be finalized when Unchecked_Deallocate_Subpool
If that's never called, then the object will
be finalized when the Pool_With_Subpools is finalized (by permission
— it might happen when the collection of the access type is finalized).
Extensions to Ada 2005
Wording Changes from Ada 2012
Corrigendum: Added missing wording to state
that the objects cease to exist after the completion of finalization.
This is formally an inconsistency (it would be possible to depend on
the fact that objects finalized by Unchecked_Deallocate_Subpool still
exist), but that violates every sane expectation for a procedure called
Clarified that the steps of deallocating a subpool
occur in a specific order. This shouldn't change any implementation;
no implementation is going to finalize deallocated objects or implement
Unchecked_Deallocate_Subpool so it is certain to raise Constraint_Error.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe