13.11.5 Subpool Reclamation
{
AI05-0111-3}
A subpool may be explicitly deallocated using Unchecked_Deallocate_Subpool.
Static Semantics
{
AI05-0111-3}
The following language-defined library procedure exists:
{
AI12-0302-1}
with System.Storage_Pools.Subpools;
procedure Ada.Unchecked_Deallocate_Subpool
(Subpool :
in out System.Storage_Pools.Subpools.Subpool_Handle)
with Global =>
in out all;
Discussion: {
AI12-0005-1}
{
AI12-0302-1}
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.
{
AI05-0111-3}
If Subpool is
null, a call on Unchecked_Deallocate_Subpool has
no effect. Otherwise, the subpool is finalized, and Subpool is set to
null.
1.
Any of the objects allocated from the subpool that still exist are finalized
in an arbitrary order;
2.
{
AI12-0148-1}
All of the objects allocated from the subpool cease to exist;
3.
The following [dispatching] call is then made:
Deallocate_Subpool(Pool_of_Subpool(Subpool).all, Subpool);
4.
{
AI12-0331-1}
The subpool ceases to belong to any pool.
{
AI05-0111-3}
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
is called.
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
{
AI12-0148-1}
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 "Deallocate" something.
{
AI12-0331-1}
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
