harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Date Tue, 19 Sep 2006 16:10:55 GMT
On 9/19/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> Ivan Volosyuk wrote:
> > On 9/19/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> >> Robin Garner wrote:
> >> >
> >> >>>
> >> >>> I don't understand. How can weak references help short-lived objects
> >> >>> reclaim?
> >> >>
> >> >> Really what I'm saying is that this is the closest thing we have to
a
> >> >> hint to GC that objects can be collected soon - but it is not
> >> anything
> >> >> like a proper free() call. There is no immediate reclaim of memory,
> >> >> just the possibility that it will be reclaimed soon - and the object
> >> >> may be garbage collected before you are finished with it!
> >> >>
> >> >> Regards,
> >> >> Oliver
> >> >>
> >> >
> >> > Actually, it's kind of the other way around isn't it ?  Nulling the
> >> > last pointer to an object tells the GC that it can collect it
> >> > (explicitly in the case of reference counting), whereas having a Weak
> >> > Reference to an object says 'please tell me when on-one else wants
> >> > this object', which results in the object staying around even longer.
> >>
> >> Isn't this only the case if you register the WeakReference with a
> >> ReferenceQueue?
> >> If you do not do that, then the GC can collect the referent when it
> >> wants, and you will
> >> just get a null back from a get() call on any WeakReference object.
> >> So I imagine that keeping the object weakly reachable and not
> >> registering it with
> >> a ReferenceQueue says to the GC "you are free to collect this referent
> >> object at the
> >> next collection if you wish".
> >
> > It is always better not to have any references to an object in heap
> > then to have a WeakReference to it.
>
> Yup, agreed!
>
> > The object without references is
> > simply garbage, while WeakReference is a kind of reference to it and
> > require handling - updating on object relocation, zeroing when object
> > no longer reachable.
>
> Agreed - but I wasn't comparing it to an object with no references. I was
> merely saying that rather than having a strong reference to a very short
> lived object, that will definitely not be garbage collected until the strong
> reference goes out of scope or is explicitly nullified, having only
> WeakReferences
> to the object could allow it to be collected ealier. I know it's not
> guaranteed,
> but there is a possibility. It's also probably not the best thing to do
> - it was
> just a comment on the ability to have short lived objects gc'ed earlier :)

Well, Oliver, if you have a strong reference to short-lived object,
you have it for a reason. This means that you do some actions with it.
It will be a failure when the reference to the object suddenly become
a null reference (what is normal for WeakReference). If you no longer
need that object - that means the live of it has just come to an end.
Short live :)

After that, no more need for WeakReference to the object. Before that,
hard reference is required by the algorithm used. There is no place
here for WeakReference.

May be I don't understand your point here. I don't see a way how
WeakReference can be used together with short lived objects.

-- 
Best regards,
Ivan

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message