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 <[EMAIL PROTECTED]> wrote:
On 9/19/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: > Ivan Volosyuk wrote: > > On 9/19/06, Oliver Deakin <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- www.FaeLLe.com www.VikramMohan.com
