[gclist] A problem with the Baker treadmill.

[Charles Fiterman]

>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
>of allocation?

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
the collectors.
			-  
Charles Fiterman		Geodesic Systems
414 North Orleans Suite 410	Phone 312 832 1221 x223
Chicago IL 60610-4418		FAX   312 832 1230
				http://www.geodesic.com

A computer language without garbage collection
  is like a city without garbage collection.