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.