History of finalizer execution and gc progress?

[Kirk Pepperdine]

Hi Stephan,

>> finalization uses a helper thread to do the actual work so there should be no direct impact. However, finalization needs to complete before a collection can finally reclaim the memory used by the object. Until then the object will need to be processed as an object waiting for finalization.
> 
> Sure, but that doesn't address my question, whether in ca. 2005 JVMs one "malicious" blocking finalizer invocation could have blocked /all/ garbage reclamation (incl. of objects without explicit finalizers).

To clarify my answer, no, not that I’ve seen in the code or have experienced.

> 
>> If your finalize method kills the helper thread, I think you have to wait for a GC cycle to end for a new finalization sequence to be triggered and that could be disruptive.
> 
> No killing of any JVM's helper threads involved.
> 
>> That said, your (albeit brief) description of the problem suggests that you can manage object clean up on your own which implies that you don’t need finalization.
> 
> No.  Let me rephrase:  Assume we continuously create and let become unreachable again three kinds of objects.  A objects don't have explicit finalizers; B objects have explicit finalizers (that are "well behaved" and execute quickly); C objects have explicit finalizers that are "malicious" and can take arbitrarily long to execute.
> 
> Now, the question is whether it would have been common behavior for a ca. 2005 JVM that a very long-running finalizer execution for a C object would have prevented timely reclamation of A objects (in addition to reclamation of B objects and other C objects).

I might wrap C in a PhantomReference and deal with them on my own if; 1) I was unable to deal with them as a closable resource (IOWs, I didn’t have a handle on the complete lifecycle for what ever reason), it was disruptive to having B finalized.

Regards,
Kirk