Test

Thu Sep 17 00:16:00 GMT 1998

>> The GC we're using now (and the one that will be in our runtime
> release) is the popular Boehm conservative collector. It solves your
> particular problem by stopping all the threads (using system-specific
> voodoo) and then doing its work.

 Actually, the problem I was getting at does not occur with conservative
collectors, so it won't be a problem with Boehm's. You seems to be describing
the stop-and-collect character of Boehm's gc.
My question is more concerned with what you do when your compiler
creates type maps (information that says what machine state,
including stack state refers to which objects). Then, it is often
so that this information is not available for every instruction,
but only a subset of instructions. An instruction for which it is 
available is called a gc point, because if a thread is stopped there, 
sufficient information is available to enable garbage collection.
Now if you have a preemptive threading system, then threads can be
stopped anywhere when you're trying to garbage collect: they do not
necessarily have to have reached a gc point. That is the hard 
problem which is unique to precise collectors in a fully preemptive
setting. (In a cooperative threading model, you can ensure that
thread switches only occur at gc points.)
Now I'm not suggestive here: I don't know how you would do it:
maybe find a new way of encoding type maps that is contiguous,
maybe find a quick way of rolling such threads forward; maybe
even roll them backward; maybe allow only thread-local precise 
collection and do a conservative global collection. I think Amer
Diwan suggested rolling forward in the paper I mentioned; though 
it is not known how efficient and doable that is. It sounds hard
and inefficient.
	- Godmar