Oleksiy Stashok wrote:
>>>
>>>> I haven't had a chance to look in detail at the implementation
>>>> details of the SlabMemoryManager and how it's used. But, I did
>>>> notice in the object diagram for Slab, a finalize() method.
>>>> Depending on how Slab and the classes that inherit Slab are used,
>>>> we might consider looking into the possibility of migrating to
>>>> using a "ReferenceQueue" approach to clean things up rather than
>>>> using finalize().
>>>>
>>>> finalize() can be problematic in that it may take several gc events
>>>> for an object with a finalize() method to get collected.
>>> I see, currently we override finalize just for statistics reasons
>>> (we calculate total amount of reclaimed memory). In this case, IMHO,
>>> we can just make sure, that even if finalize() is called several
>>> times for single object - we will calculate statistics right way.
>>>
>>
>> What I really meant by "finalize() can be problematic in that it may
>> take several gc events for an object with a finalize() method to get
>> collected." is that using a finalizer in general is problematic, not
>> anything specific about what Slab.finalize() was doing as being
>> problematic. It's the use of a finalizer itself.
>>
>> In short, any object with a finalize() method will most of the time
>> require at least 2 gc events to be fully garbaged collected. The
>> first gc event usually just puts the object on the finalizer queue,
>> the 2nd gc event will then execute the finalize() method and finish
>> collecting it. In cases where the finalizer queue depth is deep, the
>> entire queue may not get cleared in one gc event. In such as case,
>> an object with a finalize() method may sit on on the finalizer queue
>> for multiple gc events beyond the first gc event place the object on
>> the finalizer queue. So, it is possible in some circumstances for an
>> object with a finalize() method to take more than 2 gc events to be
>> collect, (1 gc event to get put on the finalizer queue, 1 or more
>> additional gc events to get pulled off the finalizer queue and be
>> executed).
>>
>> In short, it's best to avoid using a finalize() method.
>>
>> Hope that makes more sense?
> Yes :)
> Just one more question... Does it make any difference for GC, when
> finalize() method is overriden? When object doesn't override finalize,
> GC doesn't perform "finalization" at all?
Only when Object.finalize() is overridden does GC perform finalization.
Notice that Object.finalize() is an empty method which is why GC won't
do finalization on every object as a result of every object implicitly
extending Object.
charlie ...
>
> Thanks.
>
> Alexey.
>
>
>>
>>
>> thanks,
>>
>> charlie ...
>>> Thanks.
>>>
>>> WBR,
>>> Alexey.
>>>
>>>>
>>>>
>>>> charlie ...
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>