views:

553

answers:

4

I have found some great articles (Maoni, Richter #1, Richter #2) giving many details as to the theory and practice of the GC, yet I cannot find anything that states how the GC's thread priority is set.

The closest I've found is this one that states that the Finalizer thread "runs asynchronously to the application and at a high priority."

I always thought that it was a "low-priority" thread, but reading more and more about it that seems to be wrong (since the GC has to block all your other threads, and you don't want to have your app depend on a low-priority thread in order to resume in a timely fashion).

Does anybody know for sure know what the actual priority is supposed to be?

+5  A: 

The GC thread runs at a normal priority. The finalizer thread runs at "Highest" priority.

You can see this by turning on the Debug "Thread" window, and breaking anywhere in a managed application. The threads are all listed (although they're not named), with their priorities. It takes a bit to decipher which is which, but there will be an extra "Normal" and "Highest" priority thread, which correspond to the GC and the Finalizer thread.

Reed Copsey
That seems to make sense (normal for GC, highest for finalizer so as to get back without being pre-empted). I just wonder why that is not explictly explained anywhere on MSDN. Have you been able to find anything more "formal" than just firing up the Thread window?
Erich Mirabal
I don't know of anything specific. I learned about some of this a while back at a conference talk by Rico Mariani talking about perf. in .NET - However, most of the MSDN docs basically say to ignore the GC internals and just trust them - and also don't rely on them staying the same, because they're free to change at any point (and have in the past).
Reed Copsey
+8  A: 

In CLR via C#, Richter explains that:

A special high-priority CLR thread is dedicated to calling Finalize methods

(see the "Finalization Internals" heading of chapter 20)

This is the only context in which he talks about a garbage collector thread. A little earlier in the chapter, he explains that garbage collection is started in response to one of the following events:

  • Generation 0 is full
  • Call to GC.Collect
  • Windows is reporting low memory conditions
  • The CLR is unloading an AppDomain
  • The CLR is shutting down

...which suggests that the only thread created by the garbage collector is this single, "high-priority" finalizer thread.

Edit: He then goes on, in "Concurrent Collection", to explain that:

On a multiprocessor system running the workstation version of the execution engine, the garbage collector has an additional background thread to collect objects concurrently while the application runs. [...] The garbage collector has a normal priority background thread that marks unreachable objects.

Tim Robinson
This seems as close to a full answer as I might get. I'll leave it open a bit longer, but I think this might do it. Thanks! Learn something new everyday, huh? Maybe I should buy his book.
Erich Mirabal
I can definitely recommend his book -- it's interesting background information, and it's saved me on a few specific problems.
Tim Robinson
I think this is one of those rare instances where I could not find the answer online, but a book seems to have the answer in full detail. Thanks!
Erich Mirabal
Does that mean that the Finalizer thread spawns a new thread for each Finalize method he calls, or does he run the Finalize methods himself? Or perhaps he uses a pool of threads (ThreadPool?).
DonkeyMaster
The finalizer thread maintains a single queue of objects that need finalization, and runs finalizers in sequence.
Tim Robinson
A: 

the garbage collector runs at lower priority than critical threads

A: 

The GC thread priority is an implementation detail, right now they are running in normal priority, however the finalizer thread is running as a high priority and has a timeout as well.

mfawzymkh