A bit of conjecture here. It is possible for an object to be finalized and garbage collected even if there are references to it in local variables on the stack, and even if there is an active call to an instance method of that object on the stack! The requirement is that the object be … Read more
Java 9 introduces the Cleaner and Cleanable utility classes which take care of wiring up phantom references to a queue and a cleaning thread draining that queue. While this lets you separate out the witness that will perform a post-mortem cleanup after the owning object has died, all the caveats about GC-triggered resource management still … Read more
Another way of looking at this – rather than just quoting the spec which says that structs can’t/don’t have destructors – consider what would happen if the spec was changed so that they did – or rather, let’s ask the question: can we guess why did the language designers decide to not allow structs to … Read more
Although the question was asking about the Object.finalize method, the subject really is about the finalization mechanism as a whole. This mechanism includes not only the surface API Object.finalize, but it also includes specifications of the programming language about the life cycle of objects, and practical impact on garbage collector implementations in JVMs. Much has … Read more
I’m going out on a limb here, but… most people don’t need the full-blown dispose pattern. It’s designed to be solid in the face of having direct access to unmanaged resources (usually via IntPtr) and in the face of inheritance. Most of the time, neither of these is actually required. If you’re just holding a … Read more
1) Is there a well-defined difference between “destructor” and “finalizer” as used in industry or academia? There certainly appears to be. The difference seems to be that destructors are cleanup methods that are invoked deterministically, whereas finalizers run when the garbage collector tells them to. 2) In that case, the C# spec gets it wrong … Read more
Ok, it’s known that GC implicitly calls Finalize methods on objects when it identifies that object as garbage. No no no. That is not known because in order to be knowledge a statement must be true. That statement is false. The garbage collector does not run finalizers as it traces, whether it runs itself or … Read more
Herfried Wagner has written an excellent article explaining how to implement this – alas, in German (and VB). Still, the code should be understandable. I’ve tried it: static readonly Finalizer finalizer = new Finalizer(); sealed class Finalizer { ~Finalizer() { Thread.Sleep(1000); Console.WriteLine(“one”); Thread.Sleep(1000); Console.WriteLine(“two”); Thread.Sleep(1000); Console.WriteLine(“three”); Thread.Sleep(1000); Console.WriteLine(“four”); Thread.Sleep(1000); Console.WriteLine(“five”); } } It seems to … Read more
Yes, although it is not the so much the variable name that causes this, not directly. When Python exits, all modules are deleted too. The way modules are cleaned up is by setting all globals in a module to None (so those references no longer refer to the original objects). Those globals are keys in … Read more
It does for C# (see code below) but not for C++. using System; class Test { Test() { throw new Exception(); } ~Test() { Console.WriteLine(“Finalized”); } static void Main() { try { new Test(); } catch {} GC.Collect(); GC.WaitForPendingFinalizers(); } } This prints “Finalized”