[gclist] A problem with the Baker treadmill.
Mon, 13 Jan 1997 14:44:59 -0600
>BTW, some info on your system might be helpful. Are you using Be
>threads, and are they switched unpredictably? How fast are the
>synch instructions? Do you have a separate GC thread, or do you
>fake it by doing some GC work by an out-of-line call every n bytes
Users can do an atom of collection work by calling gcMinwork() they
can also arrange for n calls to gcMinwork() at every allocation. We
find two keeps the collector ahead of any problems.
There are great advantages to a write barrier system for finalizers.
If a finalizer saves a pointer to something on the white queue it
gets moved to the gray queue. We can end up with finalized objects
still living but never pointers to free objects.
Further finalizer objects can be sorted. The key AHA here is that
finalizer order is purely in the semantics of the program and cannot
be deduced by examining objects at run time. Suppose we have a file
object who's finalizer closes it, a buffer object whose finalizer
writes it to a file, and a counter object who's finalizer writes it
to the buffer with some decoration. While there will be a pointer
from the buffer to the file there will be none between the counter
and the buffer. That relationship is purely in the program semantics.
So the file object requires no unfinalized objects to finalize and
gets an order number of MAX_INT by default. The buffer gets anything
less than that say MAX_INT-1 and the counter anything less than that
say MAX_INT-2. Finalizer order is either trivial to state or trivial
to prove impossible. In either case its the programmers job and not
Charles Fiterman Geodesic Systems
414 North Orleans Suite 410 Phone 312 832 1221 x223
Chicago IL 60610-4418 FAX 312 832 1230
A computer language without garbage collection
is like a city without garbage collection.