freachable queue and finalization queue

What is difference between freachable queue and finalization queue? One Solution:Transition from Finalization Queue to FReachable Queue .net Garbage Collection

Both queues are for the purpose of managing finalizable objects.

Reference : What do you know about Freachable queue?

Freachable what? You might ask. Freachable (pronounced F-reachable) is one of CLR Garbage Collector internal structures that is used in a finalization part of garbage collection. You might have heard about the Finalization queue where every object that needs finalization lands initially. This is determined based on whether he has a Finalize method, or it’s object type contains a Finalize method definition to speak more precisely. This seems like a good idea, GC wants to keep track of all objects that he needs to call Finalize on, so that when he collects he can find them easily. Why would he need another collection then?

Well apparently what GC does when he finds a garbage object that is on Finalizable queue, is a bit more complicated than you might expect. GC doesn’t call the Finalize method directly, instead removes object reference from Finalizable queue and puts it on a (wait for it.. ) Freachable queue. Weird, huh? Well it turns out there is a specialized CLR thread that is only responsible for monitoring the Freachable queue and when GC adds new items there, he kicks in, takes objects one by one and calls it’s Finalize method. One important point about it is that you shouldn’t rely on Finalize method being called by the same thread as rest of you app, don’t count on Thread Local Storage etc.

But what interest me more is why? Well the article doesn’t give an answer to that, but there are two things that come to my mind. First is performance, you obviously want the garbage collection to be as fast as possible and a great deal of work was put into making it so. It seems only natural to keep side tasks like finalization handled by a background thread, so that main one can be as fast a possible. Second, but not less important is that Finalize is after all a client code from the GC perspective, CLR can’t really trust your dear reader implementation. Maybe your Finalize will throw exception or will go into infinite loop? It’s not something you want to be a part of GC process, it’s much less dangerous if it can only affect a background thread.