Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand
xueming.shen at oracle.com
Sat Apr 2 08:15:14 UTC 2011
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