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

[Robert Fischer]

If A has a reference to B, how did B become finalizable?

Is it something like this?

root ---> A ---> B
root ----> null  (leaving A ---> B both stranded)

Will the finalizer then consider both A and B eligilble for
finalization?  I always assumed A was then eligible for finalization,
but B isn't.

~~ Robert.

On Sat, Apr 2, 2011 at 4:15 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 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
>>>
>>
>>
>
>