Re: Traversing the stack frame and identifying "references"

Sorry for the slow reply; my GC list email was buried in a closed  
folder.

> Thanks for the link. It was very useful. I have one more question  
> though. In order to suspend all the threads, the GC needs to have  
> information about all the other threads created, e.g. handle to  
> threads etc. In controlled environments like JVM, its ok, as each  
> newly created thread can be recorded with GC. But how can it be  
> done when the garbage collector is written for languages like C++.  
> Do we need to somehow ask the compiler to do that? Or some other  
> techniques are used?

The Boehm-Weiser collector might have some code doing this.

When I worked at NaturalBridge, we solved this by doing our
own user-mode thread system with compiler-enforced cooperation.
So, all the threads are known to the GC/runtime, and the actual
number of running threads is about as many as the number of
processors on the computer, though the number of "threads"
visible to the running program might be much larger.

One thing to watch out for is time spent scanning thread
stacks.  One of our design goals was support for a very
large number of threads, and with enough threads, the space
used by thread stacks can become larger -- much larger than
a typical young space, in a generational collector.  (For
example, 32k threads, 4k stack each, gives you 128m of thread
stack.  The 4k stack/thread number assumes coloring of stack
slots to make activation records more compact, and also assumes
automatically growable stacks, because often 4k is not
enough, but many times it is.)

The interaction with native code and native threads is an
interesting mess.  One consequence of our design was that the
GC did not "bother" threads running native code, and at the
time that we took benchmarks, seemed to make code that was
native-compute-bound run about 15% faster.  I observed this
myself with a program for processing JPEG images, and one
trial user remarked "okay, so how is you Java compiler making
my C++ run faster?"

David Chase