procedure calls seems to be a natural implementation approach. If this approach is
not fine-grained enough, one could consider generating recovery points at every
procedure entrance.
1
Rec1 = POINTER TO Rec1Desc;
2
Rec1Desc = RECORD
3
i :INTEGER;
4
END;
5
6
Rec2Desc = RECORD (Rec1)
7
i :INTEGER;
8
END;
9
10 PROCEDURE Foo ( i : INTEGER; VAR a : Rec1Desc ; b : Rec1) : INTEGER
11 VAR
12
int : INTEGER;
13
c: Rec2;
14 BEGIN
15
….
16 END;
In the above example, all parameters i, a, and b of procedure Foo must be
included in the recovery point. The size of all basic types as well as records passed
as VAR parameters is already known at compile time, and thus the compiler can
directly emit the code for the recovery frame preparation.
The more complicated case that needs discussion here is pointers. First of all, a
pointer has a type, which means that this pointer can only point to objects of a
certain type or an extension of the pointer type. The actual size of an object is
accessible by its type tag.
However, the tricky part with pointers is that they can point to different objects
over the course of time or even to invalid locations such as NIL.
In addition, a pointer could point to a linked list of objects that are manipulated
in a procedure. The question that arises in this case is how to take these into
account.
Two strategies could be used:
First, for every assignment to a pointer type (procedure parameters of pointer type
are here also included), the assigned object must be included in a recovery procedure frame. On the implementation side, the compiler could add code to the type
tag that creates a new recovery point covering this object.
Whenever an object is assigned to a pointer, the compiler emits code that triggers
this code. Using flow analysis, it is also possible to find out if an object is
write-accessed or only read-accessed in the context of a procedure. In the latter
case, the object need not be stored. Obviously, this approach possibly results in a
huge number of recovery points.
8.6 Implementation Aspects
129
not fine-grained enough, one could consider generating recovery points at every
procedure entrance.
1
Rec1 = POINTER TO Rec1Desc;
2
Rec1Desc = RECORD
3
i :INTEGER;
4
END;
5
6
Rec2Desc = RECORD (Rec1)
7
i :INTEGER;
8
END;
9
10 PROCEDURE Foo ( i : INTEGER; VAR a : Rec1Desc ; b : Rec1) : INTEGER
11 VAR
12
int : INTEGER;
13
c: Rec2;
14 BEGIN
15
….
16 END;
In the above example, all parameters i, a, and b of procedure Foo must be
included in the recovery point. The size of all basic types as well as records passed
as VAR parameters is already known at compile time, and thus the compiler can
directly emit the code for the recovery frame preparation.
The more complicated case that needs discussion here is pointers. First of all, a
pointer has a type, which means that this pointer can only point to objects of a
certain type or an extension of the pointer type. The actual size of an object is
accessible by its type tag.
However, the tricky part with pointers is that they can point to different objects
over the course of time or even to invalid locations such as NIL.
In addition, a pointer could point to a linked list of objects that are manipulated
in a procedure. The question that arises in this case is how to take these into
account.
Two strategies could be used:
First, for every assignment to a pointer type (procedure parameters of pointer type
are here also included), the assigned object must be included in a recovery procedure frame. On the implementation side, the compiler could add code to the type
tag that creates a new recovery point covering this object.
Whenever an object is assigned to a pointer, the compiler emits code that triggers
this code. Using flow analysis, it is also possible to find out if an object is
write-accessed or only read-accessed in the context of a procedure. In the latter
case, the object need not be stored. Obviously, this approach possibly results in a
huge number of recovery points.
8.6 Implementation Aspects
129