Hi all,
Please review this small change that fixes this bug in System.runFinalization()
and Runtime.runFinalization().
Bug: https://bugs.openjdk.java.net/browse/JDK-4354680
Webrev: http://cr.openjdk.java.net/~smarks/reviews/4354680/webrev.0/
This is probably the simplest approach, which is to reassert the interrupt bit
if an InterruptedException is caught.
I'm slightly concerned by this, though, since if the join() was interrupted
(either because an interrupt was received while waiting to join the thread, or
the caller's interrupt bit was set at the time join() was called), the method
will return immediately, without waiting for pending objects to be finalized.
This seems to violate the spirit (if not the letter) of this method's specification.
This is the way runFinalization() has always behaved, though. The only
difference with this change is that the interrupt bit is restored instead of
being cleared.
One could imagine an alternative approach which would loop until the secondary
finalizer thread actually completes. However, it's hard for me to imagine any
code relying on runFinalization() synchronously clearing the finalization queue.
Since objects become finalizable asynchronously, how would the caller know that
the "right" set of objects had been finalized? It seems to me that this isn't
very useful, it's a change in behavior, and it's harder to test.
If we don't wait for the secondary finalizer thread to complete, perhaps it
would be appropriate to add a note to the doc about the early return in case of
an interrupt. Perhaps something like,
If the calling thread is interrupted before or during this call,
this call may return before all outstanding finalizations have been
completed, and the calling thread's interrupt status will be set.
Would something like this be appropriate? Probably this would be added to both
System.runFinalization() and Runtime.runFinalization().
s'marks
