If suppose an object implements the Finalize method but inside it refers an alive static object of the application (bad design! but very possible).
Now when GC kicks in and finalises the object by putting it in Finalization queue and then move it to FReachable queue where it would call its finalize method.
But whoa! it finds its referring an alive object so it doesnt allow GC to reclaim the memory occupied by the object and marks the object alive again. A zombie object!
At this point where does this object reside?
- Remains in freachable?
- Remains in Finalization queue?
- Remains on managed heap in an indeterminate state (removed from freachable and finalization queues)?
Also what can be the best place to ReRegisterForFinalize() for such object?
That does not matter. An outgoing reference is irrelevant for GC.
Another scenario is where the finalizing objects makes itself reachable again, by registering itself into some rooted list.
This is called resurrection. It does not require much special attention from the GC: the finalizers are processed and the reference is removed from fReachable. Note that there is nothing special, objects in fReachable are not in an indeterminate state at any time. They have to be rescanned in the next GC collection. One of the costs of a finalizer is needing 2 rounds of the GC.
Usually the object would call
ReRegisterForFinalize(this)when it resurrects.But please note that resurrection is far from a common practice.