There have been various threads (none recent) about the ability to
`finalize' objects before they get GCd, and how CL doesn't specify it.
One of the arguments against it (as a standard facility) has been
that it's not clear when, if ever, it might run. I was looking at the
Sun JDK 2 release notes, and I found this interesting text, which I
thought was interesting (it does look as if they are / have moved to a
cleverer generational GC, as well):
---cut for sun text---
In JDK 1.0 and 1.1, the runtime systems finalize objects (invoke their
finalize methods) somewhat aggressively. Sometimes all eligible but
unfinalized objects would be finalized at the end of nearly every
garbage-collection cycle. Code written for such systems can
unintentionally depend upon this prompt garbage collection-invoked
finalization for correct operation, which can lead to complicated bugs
and deadlocks.
In Java 2 SDK for Solaris, finalization is not performed directly by
the garbage collector. Instead, objects are finalized only by a
high-priority thread. So, in a busy program, the time between the
moment an object becomes eligible and the moment when it is finalized
might be longer than in previous versions of the runtime system.
In Java 2 SDK for Solaris, the runtime system properly implements the
definition of finalization in the JLS, so this difference is not,
strictly speaking, an incompatibility. This change might, however,
cause programs to malfunction if they rely upon prompt finalization.
Many such programs can be repaired by using reference objects instead
of finalize methods. (Reference objects are implemented by the
java.lang.ref.Reference class and its subclasses.) A less preferable
workaround is to periodically invoke the System.runFinalization method
at regular intervals.
··········@tfeb.org (Tim Bradshaw) writes:
> There have been various threads (none recent) about the ability to
> `finalize' objects before they get GCd, and how CL doesn't specify it.
> One of the arguments against it (as a standard facility) has been
> that it's not clear when, if ever, it might run.
It *is* clear when it *won't* run, though.
Tim Bradshaw wrote:
> There have been various threads (none recent) about the ability to
> `finalize' objects before they get GCd, and how CL doesn't specify it.
> One of the arguments against it (as a standard facility) has been
> that it's not clear when, if ever, it might run.
Yes, you always have to take the possibility of partial failures into
account - for example, in the presence of bugs or potential hardware
failures.
I wonder why most systems make this issue so complicated. For example,
in the Oberon system you didn't have to deal with finalization at all.
They have found a very clever solution for dealing with files -
essentially, file operations and file directory operations were
separated, and they implemented a kind of file system garbage collector.
(It would be nice if something like this were available for Common Lisp.)
For other kinds of resources, I think leasing protocols are the best
solutions. See for example
http://wwws.sun.com/software/jini/specs/jini1.2html/lease-spec.html
All the best,
Pascal
--
Given any rule, however �fundamental� or �necessary� for science, there
are always circumstances when it is advisable not only to ignore the
rule, but to adopt its opposite. - Paul Feyerabend