How is an object marked as finalized in Java (so that the finalize method wouldn't be called the second time)?

Question

The main question is in the topic but let me show my vision of finalization proccess in Java so that I can ask you a little more.

Well the gc starts garbage collection by marking all live objects. When all reachable objects are marked as "live". All other objects are unreachable. The next step is to check every unreachable object and determine whether it can be sweeped right now or it should be finalized at first. The gc thinks the next way if the object's finalize method has a body then this object is finalizable and should be finalized; if the object's finalize method has an empty body (protected void finalize(){ }) then it is not finalizable and can be sweeped by gc right now. (Am I right about it?)
All finalizable objects will be put in the same queue to be finalized later one by one. As I understand a finalizable object can spend a lot of time being placed to the queue while waiting for its turn to be finalized. This can happen because normally only one thread called Finalizer are taking objects from the queue and call their finalize method, and when we have some time consuming operations in some object's finalize method the other objects in the queue will be waiting pretty long to be finalized. Well when an object has been finalized it is marked as FINALIZED and removed from the queue. During the next garbage collection process the collector will see that this object is unreachable (again) and has non-empty finalize method (again) so this object should be put in the queue (again) - but it won't because the collector somehow see that this object was marked as FINALIZED. (This is my main question: in what way this object was marked as FINALIZED, how the collector knows that this object shouldn't be finalized again?)

Oxpecker

Answer 1

As long as we are talking about HotSpot JVM ...

Object itself IS NOT marked as finalized.

Each time when you create new finalize object, JVM creates an extra object FinalizerRef (which is somewhat similar with Weak/Soft/Phantom references).

Once your object is proven to unreachable with strong references special references to this object are processed. FinalizerRef for you object will be added to finalizer queue (which is linked list, same as with other reference types).

When finalizer thread consumes FinalizerRef from queue it would null its null pointer to object (though thread will keep strong reference to object until finalizer is finished).

Once FinalizerRef is nullified, object cannot get to finalizer queue any more.

BTW

You can see preference processing times (and number of references) in GC logs with -XX:+PrintReferenceGC (see more GC diagnostic JVM options)

Mishmash

Thanks. This is exactly what I was looking for. I investigated these classes Finalizer and FinalReference and now I clearly understand how it works – Oxpecker

Answer 2

The JVM stores meta data in the object header. Any object with a sub-classes finalize() is called, even if empty. Placing in the queue doesn't take long, but it can wait in the queue for a long time.

Tautology

I can believe that JVM can modify the object header to mark it FINALIZED. But I was doing some investigation and I could see a situaion when an object with empty finalize() was removed just after one garbage collection. What I'm trying to say is if this object was put to the queue to be finalized it would required at least two garbage collections to be removed (one gc - to put the object into the queue, second gc - to remove the object after it is FINALIZED). And really when I added System.out.println("I'm finalized") inside the finalize() this object was removed after two garbage collections – Oxpecker

@AntonKasyanchuk You could be right that the JVM can short cut this process, but I wouldn't assume this is always the case. – Tautology

The specification does not require but strongly encourage to detect “trivial finalizers”, which includes empty methods and methods solely consisting of a super.finalize() call (ending up at Object.finalize())… See JLS §12.6. Finalization of Class Instances, at the end – Royston

Answer 3

I don't know how exactly the real, implemented finalizing process works, but if i had to do it, i'd do it this way - store a tri-state flag in the object metadata that tells GC if the object just stopped being in use, needs the finalizer to be run, or may be removed. You'll probably have to check the java source for details but this should be the overall pattern:

(in new)

object.metadata.is_finalized=NEEDS_FINALIZE;

(in gc)

while ((object=findUnreachableObject())!=null) {
    if (object.metadata.is_finalized==NEEDS_FINALIZE) {
        if (hasNonNullBody(object.finalize)) {
            Finalizer.addForProcessing(object);
            object.metadata.is_finalized=IN_FINALIZER_QUEUE;
        } else {
            object.metadata.is_finalized=REMOVE_NOW;
        }
    }
    if (object.metadata.is_finalized==REMOVE_NOW) {
        // destroy the object and free the memory
    }
}

(in Finalizer)

while ((object=getObjectForProcessing)!=null) {
    object.finalize();
    object.metadata.is_finalized=REMOVE_NOW;
}

Saundra

The problem is that there's nothing like findUnreachableObject in a modern GC. The only think you could get is findReachableObject, move it to survivors area, and simply forget all the unreachable garbage. As most new objects die young, this is far more efficient. – Warlike