History of finalizer execution and gc progress?

[Stephan Bergmann]

On 06/17/2014 11:00 AM, Kirk Pepperdine wrote:
> 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).

> 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).

Stephan

> On Jun 17, 2014, at 9:15 AM, Stephan Bergmann <sbergman at redhat.com> wrote:
>> 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.)