7.6.1 Completion and Finalization
1
[This subclause defines
completion and
leaving
of the execution of constructs and entities. A
master is the execution
of a construct that includes finalization of local objects after it is
complete (and after waiting for any local tasks — see
9.3),
but before leaving. Other constructs and entities are left immediately
upon completion.
{cleanup: See finalization}
{destructor: See
finalization} ]
Dynamic Semantics
2/2
{
AI-00318-02}
{completion and leaving (completed and
left)} {completion
(run-time concept)} The execution of a
construct or entity is
complete when the end of that execution
has been reached, or when a transfer of control (see
5.1)
causes it to be abandoned.
{normal completion}
{completion (normal)}
{abnormal completion}
{completion (abnormal)}
Completion due to reaching the end of execution,
or due to the transfer of control of an
exit_statement,
return statement, goto_statement exit_,
return_, goto_,
or
requeue_statement or of the selection of
a
terminate_alternative is
normal completion.
Completion is
abnormal otherwise [— when control is transferred
out of a construct due to abort or the raising of an exception].
2.a
Discussion: Don't confuse the run-time
concept of completion with the compile-time concept of completion defined
in
3.11.1.
3/2
{
AI95-00162-01}
{
AI95-00416-01}
{leaving} {left}
After execution of a construct or entity is complete,
it is
left, meaning that execution continues with the next action,
as defined for the execution that is taking place.
{master}
Leaving an execution happens immediately after its
completion, except in the case of a
master: the execution of a
body other than a package_body;
the execution of a statement; or the evaluation
of an expression, function_call,
or range that is not part of an enclosing
expression, function_call,
range, or simple_statement
other than a simple_return_statement task_body,
a block_statement, a subprogram_body,
an entry_body, or an accept_statement.
A master is finalized after it is complete, and before it is left.
3.a/2
Reason: {
AI95-00162-01}
{
AI95-00416-01}
Expressions and statements
are masters so that objects created by subprogram calls (in aggregates,
allocators for anonymous access-to-object
types, and so on) are finalized and have their tasks awaited before the
expressions or statements
are left. Note that expressions like the condition
of an if_statement are masters, because they
are not enclosed by a simple_statement. Similarly,
a function_call which is renamed is a master,
as it is not in a simple_statement. Note
that although an accept_statement has no declarative_part,
it can call functions and evaluate aggregates,
possibly causing anonymous controlled objects to be created, and we don't
want those objects to escape outside the rendezvous.
3.b/2
{
AI95-00416-01}
We have to include function_calls
in the contexts that do not cause masters to occur so that expressions
contained in a function_call (that is not
part of an expression or simple_statement)
do not individually become masters. We certainly do not want the parameter
expressions of a function_call
to be separate masters, as they would then be finalized before the function
is called. 3.c/2
Ramification: {
AI95-00416-01}
The fact that a function_call
is a master does not change the accessibility of the return object denoted
by the function_call; that depends on the
use of the function_call. The function_call
is the master of any short-lived entities (such as aggregates
used as parameters of types with task or controlled parts).
4
{finalization (of
a master)} For the
finalization
of a master, dependent tasks are first awaited, as explained in
9.3.
Then each object whose accessibility level is the same as that of the
master is finalized if the object was successfully initialized and still
exists. [These actions are performed whether the master is left by reaching
the last statement or via a transfer of control.] When a transfer of
control causes completion of an execution, each included master is finalized
in order, from innermost outward.
4.a
Ramification: As explained in
3.10.2,
the set of objects with the same accessibility level as that of the master
includes objects declared immediately within the master, objects declared
in nested packages, objects created by
allocators
(if the ultimate ancestor access type is declared in one of those places)
and subcomponents of all of these things. If an object was already finalized
by Unchecked_Deallocation, then it is not finalized again when the master
is left.
4.b
Note that any object whose accessibility level
is deeper than that of the master would no longer exist; those objects
would have been finalized by some inner master. Thus, after leaving a
master, the only objects yet to be finalized are those whose accessibility
level is less deep than that of the master.
4.c
To be honest: Subcomponents of objects
due to be finalized are not finalized by the finalization of the master;
they are finalized by the finalization of the containing object.
4.d
Reason: We need to finalize subcomponents
of objects even if the containing object is not going to get finalized
because it was not fully initialized. But if the containing object is
finalized, we don't want to require repeated finalization of the subcomponents,
as might normally be implied by the recursion in finalization of a master
and the recursion in finalization of an object.
4.e
To be honest: Formally, completion and
leaving refer to executions of constructs or entities. However, the standard
sometimes (informally) refers to the constructs or entities whose executions
are being completed. Thus, for example, “the subprogram_call
or task is complete” really means “the execution of
the subprogram_call or task is complete.”
5
{finalization
(of an object) [distributed]} For the
finalization of an object:
6
- If the object is of an elementary
type, finalization has no effect;
7
- If the object is of a controlled type,
the Finalize procedure is called;
8
- If the object is of a protected type,
the actions defined in 9.4 are performed;
9/2
- {AI95-00416-01}
If the object is of a composite type, then after performing the above
actions, if any, every component of the object is finalized in an arbitrary
order, except as follows: if the object has a component with an access
discriminant constrained by a per-object expression, this component is
finalized before any components that do not have such discriminants;
for an object with several components with such a discriminant, they
are finalized in the reverse of the order of their component_declarations;.
9.a
Reason: This allows the finalization
of a component with an access discriminant to refer to other components
of the enclosing object prior to their being finalized.
9.1/2
- {AI95-00416-01}
If the object has coextensions (see 3.10.2),
each coextension is finalized after the object whose access discriminant
designates it.
10
{execution (instance
of Unchecked_Deallocation) [partial]} Immediately
before an instance of Unchecked_Deallocation reclaims the storage of
an object, the object is finalized. [If an instance of Unchecked_Deallocation
is never applied to an object created by an
allocator,
the object will still exist when the corresponding master completes,
and it will be finalized then.]
11/2
{
AI95-00280-01}
The order in which the finalization of a master performs finalization
of objects is as follows: Objects created by declarations in the master
are finalized in the reverse order of their creation. For objects that
were created by
allocators for an access type
whose ultimate ancestor is declared in the master, this rule is applied
as though each such object that still exists had been created in an arbitrary
order at the first freezing point (see
13.14)
of the ultimate ancestor type
; the finalization
of these objects is called the finalization of the collection{finalization
of the collection} {collection
(finalization of)} .
After the finalization of a master is complete, the objects finalized
as part of its finalization cease to exist, as do any types and
subtypes defined and created within the master.{exist
(cease to) [partial]} {cease
to exist (object) [partial]} {cease
to exist (type)} 11.a
Reason: Note that we talk about the type
of the allocator here. There may be access
values of a (general) access type pointing at objects created by allocators
for some other type; these are not finalized at this point.
11.b
The freezing point of the ultimate ancestor
access type is chosen because before that point, pool elements cannot
be created, and after that point, access values designating (parts of)
the pool elements can be created. This is also the point after which
the pool object cannot have been declared. We don't want to finalize
the pool elements until after anything finalizing objects that contain
access values designating them. Nor do we want to finalize pool elements
after finalizing the pool object itself.
11.c
Ramification: Finalization of allocated
objects is done according to the (ultimate ancestor)
allocator
type, not according to the storage pool in which they are allocated.
Pool finalization might reclaim storage (see
13.11,
“
Storage Management”), but has
nothing (directly) to do with finalization of the pool elements.
11.d
Note that finalization is done only for objects
that still exist; if an instance of Unchecked_Deallocation has already
gotten rid of a given pool element, that pool element will not be finalized
when the master is left.
11.e
Note that a deferred constant declaration does
not create the constant; the full constant declaration creates it. Therefore,
the order of finalization depends on where the full constant declaration
occurs, not the deferred constant declaration.
11.f
An imported object is not created by its declaration.
It is neither initialized nor finalized.
11.g
Implementation Note: An implementation
has to ensure that the storage for an object is not reclaimed when references
to the object are still possible (unless, of course, the user explicitly
requests reclamation via an instance of Unchecked_Deallocation). This
implies, in general, that objects cannot be deallocated one by one as
they are finalized; a subsequent finalization might reference an object
that has been finalized, and that object had better be in its (well-defined)
finalized state.
12/2
{
AI95-00256-01}
{execution (assignment_statement)
[partial]} The target of an
assignment_statement assignment
statement is finalized before copying in the new value, as explained
in
7.6.
13/2
{
8652/0021}
{
AI95-00182-01}
{
AI95-00162-01}
The master of an object is the master enclosing
its creation whose accessibility level (see 3.10.2)
is equal to that of the object. If
the object_name in an object_renaming_declaration,
or the actual parameter for a generic formal in out parameter
in a generic_instantiation, denotes any part
of an anonymous object created by a function call, the anonymous object
is not finalized until after it is no longer accessible via any name.
Otherwise, an The anonymous objects created by a function
call or calls
and by an
aggregate is s
are finalized no later than the end of the
innermost enclosing declarative_item or statement;
if that is a compound_statement, the
object is they
are finalized before starting the execution
of any statement within the compound_statement.
13.a/2
This paragraph
was deleted.To be honest: {
AI95-00162-01}
This is not to be construed as permission to call
Finalize asynchronously with respect to normal user code. For example,
13.b/2
This paragraph
was deleted.declare
X : Some_Controlled_Type := F(G(...));
-- The anonymous objects created for F and G are finalized
-- no later than this point.
Y : ...
begin
...
end;
13.c/2
This paragraph
was deleted.The anonymous object for
G should not be finalized at some random point in the middle of the body
of F, because F might manipulate the same data structures as the Finalize
operation, resulting in erroneous access to shared variables.
13.d/2
Reason: {
AI95-00162-01}
This effectively imports all of the special rules
for the accessibility level of renames, allocators,
and so on, and applies them to determine where objects created in them
are finalized. For instance, the master of a rename of a subprogram is
that of the renamed subprogram. It might
be quite inconvenient for the implementation to defer finalization of
the anonymous object for G until after copying the value of F into X,
especially if the size of the result is not known at the call site.
13.1/2
{
8652/0023}
{
AI95-00169-01}
{
AI95-00162-01}
In the case of an expression
that is a master, finalization of any (anonymous) objects occurs as the
final part of evaluation of the expression. If
a transfer of control or raising of an exception occurs prior to performing
a finalization of an anonymous object, the anonymous object is finalized
as part of the finalizations due to be performed for the object's innermost
enclosing master.Bounded (Run-Time) Errors
14/1
{
8652/0023}
{
AI95-00169-01}
{bounded error (cause) [partial]}
It is a bounded error for a call on Finalize or Adjust
that occurs as part of object finalization or assignment
to propagate an exception. The possible consequences depend on
what action invoked the Finalize or Adjust operation:
14.a
Ramification: It is not a bounded error
for Initialize to propagate an exception. If Initialize propagates an
exception, then no further calls on Initialize are performed, and those
components that have already been initialized (either explicitly or by
default) are finalized in the usual way.
14.a.1/1
{
8652/0023}
{
AI95-00169-01}
It also is not a bounded error for an explicit
call to Finalize or Adjust to propagate an exception. We do not want
implementations to have to treat explicit calls to these routines specially.
15
- {Program_Error
(raised by failure of run-time check)} For
a Finalize invoked as part of an assignment_statement,
Program_Error is raised at that point.
16/2
- {8652/0024}
{AI95-00193-01}
{AI95-00256-01}
For an Adjust invoked as part of assignment
operations other than those invoked as part of an assignment_statement the
initialization of a controlled object,
other adjustments due to be performed might or might not be performed,
and then Program_Error is raised. During its propagation, finalization
might or might not be applied to objects whose Adjust failed.
{Program_Error (raised by failure of
run-time check)} For an Adjust invoked
as part of an assignment_statement assignment
statement operation,
any other adjustments due to be performed are performed, and then Program_Error
is raised.
16.a/2
Reason: {
8652/0024}
{
AI95-00193-01}
{
AI95-00256-01}
In the case of assignments that are part of initialization,
there is no need to complete all adjustments if one propagates an exception,
as the object will immediately be finalized. So long as a subcomponent
is not going to be finalized, it need not be adjusted, even if it is
initialized as part of an enclosing composite assignment operation for
which some adjustments are performed. However, there is no harm in an
implementation making additional Adjust calls (as long as any additional
components that are adjusted are also finalized), so we allow the implementation
flexibility here. On the other hand, for an assignment_statement assignment
statement, it is important that all
adjustments be performed, even if one fails, because all controlled subcomponents
are going to be finalized. Other kinds of
assignment are more like initialization than assignment_statements,
so we include them as well in the permission.
16.a.1/1
Ramification: {
8652/0024}
{
AI95-00193-01}
Even if an Adjust invoked as part of the initialization
of a controlled object propagates an exception, objects whose initialization
(including any Adjust or Initialize calls) successfully completed will
be finalized. The permission above only applies to objects whose Adjust
failed. Objects for which Adjust was never even invoked must not be finalized.
17
- {Program_Error
(raised by failure of run-time check)} For
a Finalize invoked as part of a call on an instance of Unchecked_Deallocation,
any other finalizations due to be performed are performed, and then Program_Error
is raised.
17.a.1/1
Discussion: {
8652/0104}
{
AI95-00179-01}
The standard does not specify if storage is recovered
in this case. If storage is not recovered (and the object continues to
exist), Finalize may be called on the object again (when the allocator's
master is finalized).
17.1/1
- {8652/0023}
{AI95-00169-01}
{Program_Error
(raised by failure of run-time check)} For
a Finalize invoked as part of the finalization of the anonymous object
created by a function call or aggregate, any
other finalizations due to be performed are performed, and then Program_Error
is raised.
17.2/1
- {8652/0023}
{AI95-00169-01}
{Program_Error
(raised by failure of run-time check)} For
a Finalize invoked due to reaching the end of the execution of a master,
any other finalizations associated with the master are performed, and
Program_Error is raised immediately after leaving the master.
18/2
- {AI95-00318-02}
{Program_Error (raised by failure of
run-time check)} For a Finalize invoked
by the transfer of control of an exit_statement,
return statement, goto_statement exit_,
return_, goto_,
or requeue_statement, Program_Error is raised
no earlier than after the finalization of the master being finalized
when the exception occurred, and no later than the point where normal
execution would have continued. Any other finalizations due to be performed
up to that point are performed before raising Program_Error.
18.a
Ramification: For example, upon leaving
a block_statement due to a goto_statement,
the Program_Error would be raised at the point of the target statement
denoted by the label, or else in some more dynamically nested place,
but not so nested as to allow an exception_handler
that has visibility upon the finalized object to handle it. For example,
18.b
procedure Main is
begin
<<The_Label>>
Outer_Block_Statement : declare
X : Some_Controlled_Type;
begin
Inner_Block_Statement : declare
Y : Some_Controlled_Type;
Z : Some_Controlled_Type;
begin
goto The_Label;
exception
when Program_Error => ... -- Handler number 1.
end;
exception
when Program_Error => ... -- Handler number 2.
end;
exception
when Program_Error => ... -- Handler number 3.
end Main;
18.c
The goto_statement
will first cause Finalize(Y) to be called. Suppose that Finalize(Y) propagates
an exception. Program_Error will be raised after leaving Inner_Block_Statement,
but before leaving Main. Thus, handler number 1 cannot handle this Program_Error;
it will be handled either by handler number 2 or handler number 3. If
it is handled by handler number 2, then Finalize(Z) will be done before
executing the handler. If it is handled by handler number 3, then Finalize(Z)
and Finalize(X) will both be done before executing the handler.
19
- For a Finalize invoked by a transfer
of control that is due to raising an exception, any other finalizations
due to be performed for the same master are performed; Program_Error
is raised immediately after leaving the master.
19.a
Ramification: If, in the above example,
the goto_statement were replaced by a raise_statement,
then the Program_Error would be handled by handler number 2, and Finalize(Z)
would be done before executing the handler.
19.b
Reason: We considered treating this case
in the same way as the others, but that would render certain exception_handlers
useless. For example, suppose the only exception_handler
is one for others in the main subprogram. If some deeply nested
call raises an exception, causing some Finalize operation to be called,
which then raises an exception, then normal execution “would have
continued” at the beginning of the exception_handler.
Raising Program_Error at that point would cause that handler's code to
be skipped. One would need two nested exception_handlers
to be sure of catching such cases!
19.c
On the other hand, the exception_handler
for a given master should not be allowed to handle exceptions raised
during finalization of that master.
20
- For a Finalize invoked by a transfer
of control due to an abort or selection of a terminate alternative, the
exception is ignored; any other finalizations due to be performed are
performed.
20.a
Ramification: This case includes an asynchronous
transfer of control.
20.b
To be honest: {
Program_Error (raised
by failure of run-time check)}
This violates
the general principle that it is always possible for a bounded error
to raise Program_Error (see
1.1.5, “
Classification
of Errors”).
21
19 The rules of Section 10 imply that immediately
prior to partition termination, Finalize operations are applied to library-level
controlled objects (including those created by allocators
of library-level access types, except those already finalized). This
occurs after waiting for library-level tasks to terminate.
21.a
Discussion: We considered defining a
pragma that would apply to a controlled type that would suppress Finalize
operations for library-level objects of the type upon partition termination.
This would be useful for types whose finalization actions consist of
simply reclaiming global heap storage, when this is already provided
automatically by the environment upon program termination.
22
20 A constant is only constant between
its initialization and finalization. Both initialization and finalization
are allowed to change the value of a constant.
23
21 Abort is deferred during certain operations
related to controlled types, as explained in
9.8.
Those rules prevent an abort from causing a controlled object to be left
in an ill-defined state.
24
22 The Finalize procedure is called upon
finalization of a controlled object, even if Finalize was called earlier,
either explicitly or as part of an assignment; hence, if a controlled
type is visibly controlled (implying that its Finalize primitive is directly
callable), or is nonlimited (implying that assignment is allowed), its
Finalize procedure should be designed to have no ill effect if it is
applied a second time to the same object.
24.a
Discussion: Or equivalently, a Finalize
procedure should be “idempotent”; applying it twice to the
same object should be equivalent to applying it once.
24.b
Reason: A user-written Finalize procedure
should be idempotent since it can be called explicitly by a client (at
least if the type is "visibly" controlled). Also, Finalize
is used implicitly as part of the assignment_statement
if the type is nonlimited, and an abort is permitted to disrupt an assignment_statement
between finalizing the left-hand side and assigning the new value to
it (an abort is not permitted to disrupt an assignment operation between
copying in the new value and adjusting it).
24.c/2
Discussion: {
AI95-00287-01}
Either Initialize or Adjust, but not both, is applied to (almost) every
controlled object when it is created: Initialize is done when no initial
value is assigned to the object, whereas Adjust is done as part of assigning
the initial value. The one exception is the
anonymous
object
initialized created
by an
aggregate (both
the anonymous object created for an aggregate, or an object initialized
by an aggregate that is built-in-place);
Initialize is not applied to the
aggregate
as a whole, nor is the value of the
aggregate
or object adjusted.
24.d
{
assignment
operation (list of uses)}
All of the following
use the assignment operation, and thus perform value adjustment:
24.e
- the assignment_statement
(see 5.2);
24.f
- explicit initialization of a
stand-alone object (see 3.3.1) or of a pool
element (see 4.8);
24.g
- default initialization of a component
of a stand-alone object or pool element (in this case, the value of each
component is assigned, and therefore adjusted, but the value of the object
as a whole is not adjusted);
24.h/2
- {AI95-00318-02}
function return, when the result is not built-in-place type
is not a return-by-reference type (see 6.5);
(adjustment of the result happens before finalization of the function;
values of return-by-reference types are not adjusted);
24.i
- predefined operators (although
the only one that matters is concatenation; see 4.5.3);
24.j
- generic formal objects of mode
in (see 12.4); these are defined in
terms of constant_declarations; and
24.k/2
- {AI95-00287-01}
aggregates (see 4.3),
when the result is not built-in-place (in this case, the value
of each component, and the parent part, for an extension_aggregate,
is assigned, and therefore adjusted, but the value of the aggregate
as a whole is not adjusted; neither is Initialize called);
24.l
The following
also use the assignment operation, but adjustment never does anything
interesting in these cases:
24.m
- By-copy parameter passing uses
the assignment operation (see 6.4.1), but
controlled objects are always passed by reference, so the assignment
operation never does anything interesting in this case. If we were to
allow by-copy parameter passing for controlled objects, we would need
to make sure that the actual is finalized before doing the copy back
for [in] out parameters. The finalization of the parameter
itself needs to happen after the copy back (if any), similar to the finalization
of an anonymous function return object or aggregate
object.
24.n
- For loops use the assignment
operation (see 5.5), but since the type of
the loop parameter is never controlled, nothing interesting happens there,
either.
24.n.1/2
- {AI95-00318-02}
Objects initialized by function results and aggregates
that are built-in-place. In this case, the assignment operation is never
executed, and no adjustment takes place. While built-in-place is always
allowed, it is required for some types — see 7.5
and 7.6 — and that's important since
limited types have no Adjust to call.
24.o/2
This paragraph
was deleted.{
AI95-00287-01}
Because Controlled and Limited_Controlled are library-level
tagged types, all controlled types will be library-level types, because
of the accessibility rules (see 3.10.2 and
3.9.1). This ensures that the Finalize operations
may be applied without providing any “display” or “static-link.”
This simplifies finalization as a result of garbage collection, abort,
and asynchronous transfer of control.
24.p
Finalization of the parts of a protected object
are not done as protected actions. It is possible (in pathological cases)
to create tasks during finalization that access these parts in parallel
with the finalization itself. This is an erroneous use of shared variables.
24.q
Implementation Note: One implementation
technique for finalization is to chain the controlled objects together
on a per-task list. When leaving a master, the list can be walked up
to a marked place. The links needed to implement the list can be declared
(privately) in types Controlled and Limited_Controlled, so they will
be inherited by all controlled types.
24.r
Another implementation technique, which we refer
to as the “PC-map” approach essentially implies inserting
exception handlers at various places, and finalizing objects based on
where the exception was raised.
24.s
{
PC-map approach to finalization}
{
program-counter-map
approach to finalization}
The PC-map approach
is for the compiler/linker to create a map of code addresses; when an
exception is raised, or abort occurs, the map can be consulted to see
where the task was executing, and what finalization needs to be performed.
This approach was given in the Ada 83 Rationale as a possible implementation
strategy for exception handling — the map is consulted to determine
which exception handler applies.
24.t
If the PC-map approach is used, the implementation
must take care in the case of arrays. The generated code will generally
contain a loop to initialize an array. If an exception is raised part
way through the array, the components that have been initialized must
be finalized, and the others must not be finalized.
24.u
It is our intention that both of these implementation
methods should be possible.
Wording Changes from Ada 83
24.v
Finalization depends on the concepts of completion
and leaving, and on the concept of a master. Therefore, we have moved
the definitions of these concepts here, from where they used to be in
Section 9. These concepts also needed to be generalized somewhat. Task
waiting is closely related to user-defined finalization; the rules here
refer to the task-waiting rules of Section 9.
Wording Changes from Ada 95
24.w/2
{
8652/0021}
{
AI95-00182-01}
Corrigendum: Fixed the wording to say that
anonymous objects aren't finalized until the object can't be used anymore.24.x/2
{
8652/0023}
{
AI95-00169-01}
Corrigendum: Added wording to clarify what
happens when Adjust or Finalize raises an exception; some cases had been
omitted.24.y/2
{
8652/0024}
{
AI95-00193-01}
{
AI95-00256-01}
Corrigendum: Stated that if Adjust raises
an exception during initialization, nothing further is required. This
is corrected in Ada 2005 to include all kinds of assignment other than
assignment_statements.24.z/2
{
AI95-00162-01}
{
AI95-00416-01}
Revised the definition of master to include expressions
and statements, in order to cleanly define
what happens for tasks and controlled objects created as part of a subprogram
call. Having done that, all of the special wording to cover those cases
is eliminated (at least until the Ada comments start rolling in).24.aa/2
{
AI95-00280-01}
We define finalization of the collection
here, so as to be able to conveniently refer to it in other rules (especially
in 4.8, “Allocators”).24.bb/2
{
AI95-00416-01}
Clarified that a coextension is finalized at the
same time as the outer object. (This was intended for Ada 95, but since
the concept did not have a name, it was overlooked.)
Sponsored by Ada-Europe