Loglan 82, A micro-manual of the programming language - Basic constructs and facilities

11) Programmed deallocation

The classical methods implemented to deallocate class objects are based on reference counters or garbage collection. Sometimes the both methods may be combined. A reference counter is a system attribute holding the number of references pointing to the given object. Hence any change of the value of a reference variable X is followed by a corresponding increase or decrease of the value of its reference counter. When the reference counter becomes equal 0, the object can be deallocated.

The deallocation of class objects may also occur during the process of garbage collection. During this process all unreferenced objects are found and removed (while memory may be compactified). In order to keep the garbage collector able to collect all the garbage, the user should clear all reference variables , i.e. set to None, whenever possible. This system has many disadvantages. First of all, the programmer is forced to clear all reference variables, even those which are of auxiliary character. Moreover, garbage collector is a very expensive mechanism and thus it can be used only in emergency cases.

In LOGLAN a dual operation to the object generator, the so-called object deallocator is provided. Its syntactic form is as follows:

where X is a reference expression. If the value of X points to no object (none) then kill(X) is equivalent to an empty statement. If the value of X points to an object O, then after the execution of kill(X), the object O is deallocated. Moreover all reference variables which pointed to O are set to none. This deallocator provides full security, i.e. the attempt to access the deallocated object O is checked and results in a run-time error.

For example:

causes the same run-time error as:

The system of storage management is arranged in such a way that the frames of killed objects may be immediately reused without the necessity of calling the garbage collector, i.e. the relocation is performed automatically. There is nothing for it but to remember not to use remote access to a killed object. (Note that the same problem appears when remote access X.W is used and X=none).

Example:

Below a practical example of the programmed deallocation is presented. Consider class Bst (p.7). Let us define a procedure that deallocates the whole tree and is called with the termination of the class Bst.

Bst may be applied as a prefix:

and automatically will cause the deallocation of the whole tree after return to call kill_all(root) from the prefixed block.

To use properly this structure by remote accessing one must call kill_all by himself:

Finally note that deallocator kill enables deallocation of array objects, and suspended coroutines and processes as well (cf p.13).