OSDev.org

There are no destructors in Java, but there are finalizers. Finalizers are fairly evil in that they complicate the implementation of the GC, slow things down, and ought to be unnecessary in the first place. When you create a local object in Java and its only reference goes out of scope, it is not destroyed immediately, but the next time the GC runs there is a good chance that object will be collected. If it has a finalizer, the GC will put it on a queue to be finalized later and it is not collected immediately.

IMO a sane design for a language with garbage collection would mix stack-based objects that have deterministically-invoked destructors with GC'd heap-based objects (that do not have finalizers, ever). That way you could still use C++'s RAII technique to dispose of non-memory resources in a timely and predictable fashion, while leaving pure memory reclamation up to the system. The closest thing I've seen so far is C#'s using block, but it's really just a hack. I think in C++/CLI it's possible to mix the GC and C++ destructor paradigms a lot more. Too bad it's even more complicated and decorated (Foo^ bar; anyone?) than plain old C++...

To repeat the point I am trying to make: If you're "brought up" to believe your development platform of choice will care for everything, you are going to become someone who is unaware of the fine print. It doesn't really matter whether the problem is the JVM or the widget library or whatever, what matters is that someone who never bothered to think about memory management will have a really hard time finding bugs like that.

Or, to put it differently: I'd employ a C++-coder-gone-Java without any hesitation. I would interview a Java-coder-gone-C++ very closely before allowing him to work in my project.

Iigc, the case Solar was talking about implies that A is a static object handling the GUI. It doesn't necessarily needs to be native.

Just let's suppose that upon Gui.RegisterEvent(Gui.MouseMovedEvent, B); the static object GUI adds B (or more likely, an EventHandlerObject referencing B) into a HashTable so that it can retrieve who's interested into MouseMoved event later ...

If you now remove all references to B in your program but forget to call Gui.UnregisterEvents(B) before this, then there's a dangling reference to B in the GUI's hashtable (making B never collected), even if the window that contains B has been released an is now inactive...

The natural place where I would have called UnregisterEvents(this) would have the destructor of B (that is, if B gets out of scope, unregister everything related to B)... which would fail to work with a GC, of course.

And about "finalize()" being evil, i once had a situation where "finalize()" was very handy: for objects that stores logs. I wanted all the per-object-history written back in a file after the object's life was over, but the framework (being Java-minded) didn't provide a way to say "object X is now out of scope and won't ever be called" so all i could rely on was the "finalize()", or i might miss lately introduced entries.

No need to say that it indeed started a war between me and the GC

Finalizers in Java are not fairly evil, they are evil.

One, any exception thrown by them is ignored, the finalization of the object halted. Means: You just leaked memory, no way to recover. I agree that C++ is only marginally more friendly here - if a destructor throws an exception while another exception is currently rolled back, your program calls [tt]terminate()[/tt]. But that can be caught and handled.

Two, there is no guarantee that your [tt]finalize()[/tt] function will ever be called, not even when the JVM terminates. It is called "when and if" the GC touches the object for collecting. Which might be immediately, later, or never.

And as for performance... every Java [tt]Object[/tt] does have a finalize() function, which simply returns while doing nothing. One more function call to execute for each object finalized. (Compare this with a C++ object only having native member types - "destruction" is a nop in this case.)

I absolutely agree. My company's recruiting process is set up specifically to avoid this problem.



Ahh... I get it now. This is actually "unintentional object retention", not a memory leak per se. The problem is caused by the Gui's scope -- it is a long-lived object referring to short-lived objects.

The solution to this would be for Gui to use weak references to event handlers instead of strong references. That way, Gui's reference to B doesn't prevent B from being garbage collected. Whenever the event occurs, Gui would check its weak reference to B to see if it's still valid. If so, the event is delivered; if not, it is safe for Gui to remove B from its hashtable. In this case, the designers of Gui must have their thinking caps on.



Heh, ok. I was being charitable for cases like Pype's (although in truth Pype, writing to a log file in a finalizer scares the willies out of me...)



My teammate and I were just dealing with this issue yesterday (we're doing a lot of Java/C++ integration via the JNI this week). Even though every Java object inherits "finalize()" from java.lang.Object, only those objects that actually override finalize() are put on the finalization queue by the GC. The performance would just be too terrible otherwise.

Ahhhhh... undermining their own specs, are they?