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.

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.

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.

Regards,
Kirk

On Jun 17, 2014, at 9:15 AM, Stephan Bergmann <sbergman at redhat.com> wrote:

> Hi all,
> 
> Does anybody recollect historical details of how execution of (potentially long-running) finalizers impacted overall gc progress?
> 
> From the behavior of a small test program run on OpenJDK 8, it looks like recent JVMs at least offload all finalizer calls to a single dedicated thread, so that a blocking finalizer blocks finalization (and thus reclamation) of other garbage objects with explicit finalizers, but reclamation of other garbage proceeds unhindered.
> 
> But how was the behavior in the past?  Was it so that in older JVMs (still in use around 2005) execution of a blocking finalizer could block reclamation of /all/ garbage, even of those objects that did not have explicit finalizers?
> 
> (I'm asking because in LibreOffice we have a dedicated thread to which we offload the actual work done by certain objects' finalize methods, introduced around 2005 to work around memory starvation in case one of those finalizers took too long.  But I can't remember whether that was because no garbage at all was reclaimed in such a scenario---and we could drop our additional thread again today---, or because it blocked finalization of unrelated objects with explicit finalizers---in which case we would need to keep our additional thread.)
> 
> Stephan