Oct 26 1999. Garbage Collection Latency Why is this important? Well many times on comp.lang.smalltalk I've seen people whine that their Weak object logic doesn't run for some time after the object in question dies. A few seconds to minutes. Of course the person is counting on the logic to run immediately. This doesn't happen. Also in a previous version of VisualAge in order to address the problems explained by George Bosworth's Ephemerons the finalization code was serialized! Zap a lot of weak objects and lo it took a long time to run the finalization logic.

Garbage Collection Latency in Smalltalk
=======================================

A Smalltalk object is eligible to be garbage collected as soon as it is
no longer reachable from Smalltalk, the SystemDictionary, via a path of
non-weak object references. However, garbage objects are not reclaimed
immediately. Rather, they must wait until one of the system's four
garbage collectors gets around to reclaiming it. To help you
understand how long a garbage object must wait before being collected,
we briefly explain the various garbage collectors below.

1. The Scavenger

Scope: The scavenger collects all objects in NewSpace (i.e.,
Eden or one of the SurvivorSpaces) that are not referenced by
any object outside of NewSpace.

Frequency: Since scavenges occur whenever Eden fills up with
new objects, they normally happen with high frequency (i.e.,
one or more times per second whenever a Smalltalk process is
active). However, the scavenger does its work so quickly as
to be imperceptible to the user.

Example 1: If two garbage objects in NewSpace reference each
other, but no objects outside of NewSpace reference either of
these two objects, then the scavenger will reclaim both garbage
objects.

Example 2: If a garbage object in NewSpace is referenced by a
gabage object in OldSpace or a garbage object in PermSpace,
then the object in NewSpace will not be reclaimed by the
scavenger. Such garbage can only be collected by one of the
other three collectors.

2. The Incremental Garbage Collector

Scope: The incremental garbage collector (IncGC) reclaims all
objects in both NewSpace and OldSpace that are not referenced
by any object in PermSpace.

Frequency: The frequency with which the IncGC is run is
completely controlled by the policy code in the currently
active MemoryPolicy. By default, the IncGC may run in the idle
loop, in low-space conditions, and periodically in order to
keep up with the OldSpace death rate. How long it takes the
IncGC to complete a full reclamation depends upon a number of
factors: how much data is housed in OldSpace and NewSpace, how
much idle time is available, how compute intensive the various
active computations are, how many allocations have been
completed since the last time the IncGC was run, how many bytes
have been allocated in OldSpace recently, etc.

Example 1: If you are editing a text file and you pause to take
a sip of coffee, the IncGC may run in the background provided
you don't have any other background processes waiting to run
and provided the IncGC mechanism has reason to believe that
there is an interesting amount of garbage to reclaimed.

Example 2: If a garbage object in NewSpace is referenced by a
garbage object in OldSpace, then the IncGC will reclaim both
objects.

Example 3: If a garbage object in OldSpace is referenced by a
gabage object in in PermSpace, then the object in OldSpace will
not be reclaimed by the IncGC. Such garbage can only be
collected by the global garbage collector.

3. The Compacting Garbage Collector

Scope: The scope of the compacting garbage collector
(compactGC) is the same as that of the IncGC. In fact, the
primary difference between the CompactGC and the IncGC is that
the CompactGC compacts OldSpace whereas the IncGC does not, and
the CompactGC runs to completion once it is started whereas the
CompactGC can be interrupted and run incrementally.

Frequency: The CompactGC is rarely run. It is typically
invoked manually by selecting the 'collect garbage' option in
the Launcher. In addition, it is occasionally run under
low-space conditions.

4. The Global Garbage Collector

Scope: The global garbage collector (GlobalGC) will reclaim all
garbage that is present in the system, regardless of what space
that garbage might reside in. The GlobalGC is the only
collector that can reclaim garbage in PermSpace.

Frequency: With the exception of the Stripper facility, the
GlobalGC is not invoked directly by any system code. Although
users can invoke the GlobalGC from the Launcher, this is
typically only done as part of packaging an application for
deployment.

Example 1: If a garbage object in NewSpace is referenced by a
gabage object in PermSpace, then the GlobalGC will reclaim both
objects.

Example 2: If a garbage object in OldSpace is referenced by a
gabage object in in PermSpace, then the GlobalGC will reclaim
both objects.

We can summarize the situation as follows:

1. NewSpace Garbage

If the garbage object is in NewSpace and this object is not
referenced by any objects in OldSpace or PermSpace, then it
will be reclaimed in short order by the scavenger. All other
NewSpace garbage will not be reclaimed until one of the other
three collectors is run.

2. OldSpace Garbage

If the garbage object is in OldSpace and this object is not
referenced by objects in PermSpace, then it will be reclaimed
the next time the IncGC or the CompactGC are run. All other
OldSpace garbage will not be reclaimed until the GlobalGC is
run.

3. PermSpace Garbage

If the garbage object is in PermSpace, then it will be
reclaimed only if the user invokes the GlobalGC.

The ObjectMemory class documentation protocol and the User Guide
chapter on memory management contain additional information.