A few methods in Object support the creation of particular objects. This include:
Marks the object so that it is considered weak in subsequent garbage
collection passes. The garbage collector will consider dead an object
which has references only inside weak objects, and will replace
references to such an “almost-dead” object with nils, and then
mourn message to the object.
Marks the object so that it is considered specially in subsequent
garbage collection passes. Ephemeron objects are sent the message
mourn when the first instance variable is not referenced
or is referenced only through another instance variable in the
Ephemerons provide a very versatile base on which complex interactions with the garbage collector can be programmed (for example, finalization which is described below is implemented with ephemerons).
Marks the object so that, as soon as it becomes unreferenced, its
finalize method is called. Before
finalize is called,
the VM implicitly removes the objects from the list of finalizable
ones. If necessary, the
finalize method can mark again
the object as finalizable, but by default finalization will only occur
Note that a finalizable object is kept in memory even when it has no references, because tricky finalizers might “resuscitate” the object; automatic marking of the object as not to be finalized has the nice side effect that the VM can simply delay the releasing of the memory associated to the object, instead of being forced to waste memory even after finalization happens.
An object must be explicitly marked as to be finalized every time
the image is loaded; that is, finalizability is not preserved by an
image save. This was done because in most cases finalization is used
together with operating system resources that would be stale when the
image is loaded again. For
CObjects, in particular, freeing them
would cause a segmentation violation.
Removes the to-be-finalized mark from the object. As I noted above, the finalize code for the object does not have to do this explicitly.
This method is called by the VM when there are no more references to the object (or, of course, if it only has references inside weak objects).
This method answers whether the VM will refuse to make changes to the
objects when methods like
at:put: too (depending on the implementation of the
Note that GNU Smalltalk won’t try to intercept assignments to fixed
instance variables, nor assignments via
literals) are read-only by default.
Changes the read-only or read-write status of the receiver to that
#basicNew, but the object won’t move across garbage
#basicNew:, but the object won’t move across garbage
Ensure that the receiver won’t move across garbage collections.
This can be used either if you decide after its creation that an
object must be fixed, or if a class does not support using
#new: to create an object
Note that, although particular applications will indeed have a need for
fixed, read-only or finalizable objects, the
is seldom needed and weak objects are normally used only indirectly,
through the so called weak collections. These are easier to use
because they provide additional functionality (for example,
is able to determine whether an item has been garbage collected, and
WeakSet implements hash table functionality); they are:
Versions of GNU Smalltalk preceding 2.1 included a
which has been replaced by
WeakKeyDictionary; the usage is completely
identical, but the implementation was changed to use a more efficient
approach based on ephemeron objects.