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]
