JEP 132: More-prompt finalization (Re: Another take on Finalization)

Peter Levart peter.levart at
Tue Jun 9 06:38:18 UTC 2015

On 06/09/2015 01:41 AM, Kim Barrett wrote:
> On Jun 8, 2015, at 1:45 PM, Rezaei, Mohammad A. <Mohammad.Rezaei at> wrote:
>> If that's the case, the documentation needs to be more clear :-) It currently says:
>> "Clears this reference object.  Invoking this method will not cause this object to be enqueued."
>> I interpret that as meaning the reference will not be put on the queue as a part of the clear() call.
>> The bit of code that prevents this queuing is nowhere to be seen
> It’s in the VM; see callers of (C++) discover_reference, which all skip that call if the referent is null.
> For example:
> circa line 47


If you're looking for javadoc part where this is described, then see the 
part of for example WeakReference class documentation which says:

"Suppose that the garbage collector determines at a certain point in 
time that an object is *weakly reachable*. At that time it will 
atomically clear all weak references to that object and all weak 
references to any other weakly-reachable objects from which that object 
is reachable through a chain of strong and soft references. At the same 
time it will declare all of the formerly weakly-reachable objects to be 
finalizable. At the same time or at some later time it will enqueue 
those newly-cleared weak references that are registered with reference 

...and in addition, the description of "weakly-reachable" and 
reachability in general:

  * An object is /strongly reachable/ if it can be reached by some
    thread without traversing any reference objects. A newly-created
    object is strongly reachable by the thread that created it.
  * An object is /softly reachable/ if it is not strongly reachable but
    can be reached by traversing a soft reference.
  * An object is */weakly reachable/* if it is neither strongly nor
    softly reachable but can be reached by traversing a weak reference.
    When the weak references to a weakly-reachable object are cleared,
    the object becomes eligible for finalization.
  * An object is /phantom reachable/ if it is neither strongly, softly,
    nor weakly reachable, it has been finalized, and some phantom
    reference refers to it.
  * Finally, an object is /unreachable/, and therefore eligible for
    reclamation, when it is not reachable in any of the above ways. for an object to be "weakly-reachable" it has to be reachable by 
traversing a WeakReference. If you manually clear all WeakReferences 
pointing to an object, It will not be weakly-reachable any more, so GC 
will not do any actions that would make WeakReferences that formerly 
pointed to that object being enqueued at a later time. It can't do any 
actions, since those WeakReferences are not in any way associated with a 
referent any more after they are manually cleared.

Regards, Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the hotspot-gc-dev mailing list