Object lifetime management is a difficult issue in PCE/Prolog as PCE cannot be aware of all references to PCE objects stored in Prolog. Another complicating factor is that non-incremental garbage collection as performed by most Lisp systems is undesirable because they harm the interactive response of the system. For these reasons PCE performs incremental garbage collection. It distinguishes a number of prototypical `life-cycles' for objects. Heuristics tell the system which of these is applicable and when the object may be deleted.
PCE distinguishes between global-, top level-, support-, argument-
and answer- objects. Global objects are created and
exist for the entire PCE session: @prolog,
class objects, etc. Top-level objects are the principal objects
of the application. They should exist even if no other PCE object refers
to them. An example of a top level object is a frame or hash_table
representing a database in the application. Support objects
only complete the definition of other objects. If this `other' object is
removed, the support object may be removed as well. An example is the
area attribute of a graphical. Argument objects are objects
created to serve as an argument to a message. For example a graphical
may be moved to a position described by a point object. The point may be
deleted when the message is completed. Finally, answer objects
are the result of some computation. For example `area<-size'
returns a size object. This object may be deleted when the code that
requested the value is done with it.
PCE maintains the following information on objects to support garbage collection. This information may be requested using the PCE inspector (see section 12.5).
->protect'.
When set, the object can not be freed by any means. This flag is set for
most global and reusable objects: @prolog, @pce, @display,
names, classes, etc.
->free'
message' or using the predicate free/1.
It is used to avoid that `top level' objects such as frames are deleted
by the garbage collector. It is also used to indicate that Prolog wants
to be responsible for destruction of the object rather than PCE's
garbage collector. The lock flag is automatically set on any object that
has a named reference. If Prolog wants to store integer object
references in the Prolog database locking is often necessary to protect
the object for the PCE garbage collector. See also section
6.
<-un_answer: @off',
which implies that objects that fill a slot of a code object will not
loose their `answer' status. or `object->done'
is invoked on the object.