[MUD-Dev] Programming Languages.

[Mike Shaver]

On Jul 04, Kwon J. Ekstrom wrote:

> This is inaccurate, you're 100% guaranteed that the garbage
> collector will pick up any object and run it's finalize method if
> you remove all references to an object.  You're not guaranteed
> when this will happen.

I don't believe that's true; your finalizer is usually run, but it
doesn't have to be.  If the GC doesn't reuse the space that your
object occupies, the specification doesn't require that it calls
your finalizer, so some objects may well be left unfinalized,
especially at shutdown time.  (|system.runFinalizersOnExit| used to
be the recommended way to guarantee that, but it didn't help in
cases of abnormal termination such as in response to a signal, and
it was deprecated in 1.2 because it was unsafe.)

  http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html

has a discussion of some of the issues with finalizers.  Sun's JLS
errata at

  http://java.sun.com/docs/books/jls/class-finalization-rationale.html

also include this sentence:

  You never have a guarantee that either class or object
  finalization will in fact take place.

> Another trick (I've used this with pools) is to use the finalize
> method to create a new reference (putting the object back in the
> pool if it's below "threshold").  You're guaranteed that there
> aren't any references to it if the GC picked it up.  (not sure
> about java.lang.ref based references) This prevents the GC from
> deallocating the memory.

What do you do the second time an object goes through the zero-ref
state and is reaped?  The Java specification says quite explicitly
(S 12.6.1) that a finalizer is invoked at most once for a given
object, even if it becomes reachable and then finalizable after the
finalizer has been run (or while it's being run).

Mike
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev