Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand
robert.fischer at smokejumperit.com
Sat Apr 2 22:40:32 UTC 2011
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.
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.
> 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:-)
>>> 4a) Another thread reads the static variable and calls B.close()
>>> 4b) Finalizer thread runs B.finalize()
More information about the core-libs-dev