Menu
What is difference between freachable queue and finalization queue? One Solution:Transition from Finalization Queue to FReachable Queue .net Garbage Collection
847
The Freachable Queue is another internal data structure (Queue) controlled by the garbage collector. Each pointer in the Freachable Queue identifies an object that is ready to have its Finalize method called.
Finalize gives implicit control over releasing resources. It is called by the garbage collector. Dispose is a way to give explicit control over a release of resources and can be called directly. There is much much more to learn about the subject of Garbage Collection, but that's a start.
The finalization queue contains entries for all the objects in the managed heap whose finalization code must run before the garbage collector can reclaim their memory. This specialized CLR thread is only responsible for monitoring the freachable queue and when GC adds an item it executes the Finalize method.
Finalizers (historically referred to as destructors) are used to perform any necessary final clean-up when a class instance is being collected by the garbage collector. In most cases, you can avoid writing a finalizer by using the System. Runtime.
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.
50
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
