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

[Xueming Shen]

On 04-02-2011 12:47 AM, Xueming Shen wrote:
>  On 4/1/2011 11:56 PM, Jeroen Frijters wrote:
>> Xueming Shen wrote:
>>> 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
>> This is not correct. You can re-publish the reference from another 
>> finalizer method and thereby allow another thread to access the 
>> object concurrently with the finalizer.
>>
>> Here's a possible sequence of events:
>> 1) GC runs and determines that A and B are finalizable
>> 2) Finalizer thread run A.finalize()
>> 3) A.finalize publishes reference to B in static variable
>
> Jeroen, are you talking about the object resurrection from finalize()?
>
> How do you re-publish/get the reference to B inside A.finalize()? I 
> think you can do that inside
> B's finalize() to assign "this" to a global static variable.

Jeroen,

Guess I replied too quick. I think I got what you meant. A has a 
reference to B,  GC finalizes A
and B the same time, then A republish reference to B and let someone 
else to invoke b.close()..
I would have to admit it's a possible use scenario:-)

-Sherman

>
> Regard,
> -Sherman
>
>> 4a) Another thread reads the static variable and calls B.close()
>> 4b) Finalizer thread runs B.finalize()
>>
>> Regards,
>> Jeroen
>>
>
>