Lightweight finalization for the JDK without any drawbacks was: Why is finalize wrong?

Jaroslav Tulach jaroslav.tulach at
Fri Aug 8 10:55:00 UTC 2014

Dne Pá 8. srpna 2014 10:01:14, Andrew Haley napsal(a):
> On 08/08/14 09:01, Jaroslav Tulach wrote:
> > Given the fact that WeakReference & co. has been introduced in JDK
> > 1.2 and that version was released at the end of 1998, I bet it was
> > just a communication problem, as Andrew must have been talking about
> > something else than WeakReference + ReferenceQueue behavior.
> You don't have to believe me, read this:
> ty.html

Interesting, but not really related. Maybe a topic for the memory management group 
to require a receiver of an instance method call to be considered GC root while the 
method is running.

Btw. if anyone really gets into problems described in the article, this:

byte[] getData() {
  try {
    return array.clone();
  } finally {
    Logger.getLogger("keep").log(Level.FINEST, "alive {0}", this);

is a way to prevent GC of this while the getData() method is running. My assumption 
is that the Logger.log call is so polymorphic that it won't be possible for a VM to inline 
it and/or optimize away - even it is usually a no-op.

PS: On a similar note:[1] 

> ml
> The problem is not to do with WeakReferences or ReferenceQueues, but with
> the notion of reachability in the VM.
> The language which permits this behaviour is:
> "Optimizing transformations of a program can be designed that reduce
> the number of objects that are reachable to be less than those which
> would naively be considered reachable. For example, a Java compiler or
> code generator may choose to set a variable or parameter that will no
> longer be used to null to cause the storage for such an object to be
> potentially reclaimable sooner.
> "Another example of this occurs if the values in an object's fields
> are stored in registers. The program may then access the registers
> instead of the object, and never access the object again. This would
> imply that the object is garbage."
> Andrew.


More information about the core-libs-dev mailing list