[gclist] Re: gclist-digest V3 #84

[Charles Fiterman]

At 10:36 AM 6/20/00 -0400, you wrote:
>One more thing to keep in mind is that garbage collections, like thread
>switches, may be restricted to certain static locations in the program.
>For example, garbage collections may occur only when storage is allocated,
>which would imply that the only program points at which a procedure can be
>suspended when a garbage collection occurs are the allocation points, the
>return points, and the thread resumption points.

Most programs these days are multi threaded which means even if collection
occurs only at allocation points any thread can see it as happening anywhere. 

Most collection algorithms require stopping all threads. However relatives
of the Baker treadmill only require locking object lists or parts of them
while moving objects from one list to another. The Baker treadmill requires
an absolutely cooperating language that will tell the collector about every
store of a pointer to a collectible object. Perkin Elmer once made a
machine where moving an object from one double linked list to another was
an atomic operator. If I could ask for one machine instruction to improve
garbage collection that would be it.

---

Since we were discussing conservative collection let me point out. If a
language supports finalizers or their relatives e.g. weak pointers, death
notices etc. conservative collection is a problem. Aunt Edna's social
security number can look like a pointer and impede the collection of an
object. Now impeding the collection of an object is mostly harmless but
impeding its finalizer, death notice etc. is not harmless since mutator
semantics can depend on it. 

If the language specs say finalizers can't be relied on the best, most
portable, safest and most efficient implementation of finalizers is to
ignore them and their relations.