Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand

[Xueming Shen]

  On 4/1/2011 4:17 PM, David Holmes wrote:
> Xueming Shen said the following on 04/02/11 05:07:
>> On 04/01/2011 09:42 AM, Neil Richards wrote:
>>> On Wed, 2011-03-30 at 13:31 -0700, Xueming Shen wrote:
>>>> Isn't it true that when the finalize()->close() gets invoked, there
>>>> should be no strong reference anywhere else that you can use to invoke
>>>> close() in other thread?
>>> It's true that once finalize() has been called, there can't be another
>>> explicit call to close().
>>> However, if close() is explicitly called first, it will be called again
>>> when finalize() calls it, so one still wants the update to 
>>> 'isClosed' to
>>> be seen by the finalizer thread (in this case).
>>
>> I'm not a GC guy, so I might be missing something here, but if 
>> close() is being explicitly
>> invoked by some thread, means someone has a strong reference to it, I 
>> don't think the
>> finalize() can kick in until that close() returns and the strong 
>> reference used to make that
>> explicit invocation is cleared. The InputStream is eligible for 
>> finalization only after it is
>> "weakly" reachable, means no more "stronger" reachable exists, right?
>
> Actually no. One of the more obscure corner cases with finalization is 
> that you can actually finalize an object that is still being used. The 
> JLS actually spells this out - see section 12.6.1 and in particular 
> the Discussion within that section.
>
> David

David,

The scenario that Neil and I were discussing is something like this,

There is class A

class A {
     void close() {
         ...
     }

     protect void finalize() {
         ...
         close();
     }

}

when we are in the middle of A's close() (invoked by someone, not the 
finalizer), do we need to worry about that
A's finalize() being invoked (and then the close())  by the finalizer 
concurrently.

Does you "an object that still being used" include the scenario like 
above, which means an object became
finalizer-reachable,  when still in the middle of the execution (by some 
alive, non-finalizer-thread) of one of its
instance method body?

The JLS 12.6.1, if I read it correctly, is for scenario that a reachable 
object which is strongly referenced by a
stack reference can/may become finalizer-reachable sooner than it might 
be expected, for example, the
compiler optimization can null out such reference in the middle of the 
method body, so that object becomes
finalizer-reachable before the execution reach the return point of the 
method, or ... The "execution" discussed
is not the execution inside the target object's method body. Am I 
reading it correctly? Otherwise, it becomes a
little weird, image, you are in the middle of the execution of an 
instance method, suddenly, the instance itself
is being finalized, all the native resource get released...

-Sherman