harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From FaeLLe <mrbillcollec...@gmail.com>
Subject Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Date Sun, 01 Oct 2006 02:08:43 GMT
Perhaps he means clone the object to a WeakReference then null the original
object ?

That way the only existing copy of that object will be a WeakReference....
with my limited
understanding of GC concepts would that no be benificial ?

Regards,

- Vikram Mohan

On 9/19/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
>
> 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
>
>


-- 
www.FaeLLe.com
www.VikramMohan.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message