garbage collection - 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?)

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)