13.11.5 Subpool Reclamation
A subpool may be explicitly deallocated using Unchecked_Deallocate_Subpool.
The following language-defined library procedure
(Subpool : in out System.Storage_Pools.Subpools.Subpool_Handle);
If Subpool is null, a call on Unchecked_Deallocate_Subpool
has no effect. Otherwise, the subpool is finalized, and Subpool is set
Finalization of a subpool has the following effects:
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;
following [dispatching] call is then made:
Finalization of a Root_Storage_Pool_With_Subpools
object finalizes all subpools that belong to that pool that have not
yet been finalized.
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, 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 determinate
that, they can use that as part of the implementation of Deallocate.
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
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe