Re: [gclist] Finalization and object orientation.
Thu, 27 Mar 97 19:59:24
>Most real systems that I am familiar with use finalization
>as the cleanup-of-last-resort. So, for example, Smalltalk
>will close a window if the corresponding object gets GC'd
>but the normal usage is to close the window yourself
>when you know you're done with it. It seems quite a
>stretch to argue that the close method somehow breaks
Windows are of course a user interface element, and
typically get closed because the user did domething to close
them, so having a close method does not break encapsualtion.
But a closed window is not a destroyed window, and I would
argue that a destroy method does break encapsulation. But
of course you don't need GC for windows: every window but
one has a parent, no window's lifetime can exceed that of
its parent, and the windowing system takes care of
destroying windows itself.
>Finalization in Java is indeed poorly specified. If I had
>speculate at the reasons for this, my hunch would be to allow
>normal process-level cleanup to handle everything (if so
>desired by the VM implementer) rather than delaying process
>termination while a bunch of (redundant) finalizers are run.
File handles seem to be the kind of resource that a finalizer
is handy for: they have no owner but the process, they are
easily encapsulated in a class, and it can be hard to know
statically when the last user of file is gone. But they are
also hard to write a finalizer for: they can be a scarce
resource, the system doesn't know that when you run out you
should do a gc and finalize sweep, and they often wind up in
circular relationships with buffers. I recall a popular
Scheme implementation in which a request to open a file would
fail, but then succeed because a gc was done each time around
the main loop of the interpreter.
It might be best if common OS resources were better known to
the language runtime itself, so that you wouldn't need to
write finalizers to deal with them.