[Glass] instances not being garbage collected?

[Dale Henrichs]

Thierry,

IndexManger current getAllNscRoots will give you an IdentitySet of all nscs
with indexes ... once you identify the disconnected nsc, you can user
#removeAllIndexes to clean up the DepMap correctly...

Dale


On Sat, Mar 1, 2014 at 8:45 PM, Thierry Thelliez <
thierry.thelliez.tech at gmail.com> wrote:

> Dale,
> If I removed a reference to a collection containing an index without first
> removing the index, can I still clear the contained objects? How can one
> clean the DepMap?
>
> Thanks,
> Thierry
>
>
> On Mon, Jan 20, 2014 at 2:47 PM, Dale Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
>
>> Johan,
>>
>> Two thing come to mind right off the bat:
>>   1. did these objects participate in an index?
>>   2. have you cycled all of your gems recently
>>
>> If you are using indexes, strong references to objects will be made from
>> the DepMap (an ObjectTable-like entity that maps objects to their
>> dependents for modification tracking). Objects are managed correctly with
>> respect to the DepMap, however, if you drop a reference to a collection
>> that has an index without first removing the index, the DepMap will keep
>> objects alive. If you are not using indexes the DepMap should be empty.
>>
>> Long running gems may end up keeping references to otherwise dead objects
>> [1], especially if you haven't haven't set  GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE
>> to something like 90:
>>
>> GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE=90;
>>
>> in your system.conf. Even with the above, you are not guaranteed to prune
>> all of the persistent references on the vote. You should be suspicious that
>> you are seeing this particular problem if you consistently see a high
>> number of possible dead in your mfc report. Also look at vsd and after an
>> mfc you should see the stone stat PossibleDeadObjs jump up to the value
>> that was reported when your mfc ran ... Then a short while later (after
>> voting is complete) you should see the stone stat DeadNotReclaimedObjs jump
>> ... if DeadNotReclaimedObjs is significantly less than PossibleDeadObjs,
>> then those objects were "voted down" because one or more live gems had a
>> reference to the object in its head. If you've already got GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE
>> set to 90 you might try cycling all of your gems and run another mfc ....
>>
>> If your PossibleDeadObjs from an mfc is not as high as you think it
>> should be, then I will have to do some more research on finding out if
>> there are any other "hidden" references to objects ...
>>
>> Dale
>>
>> [1] https://code.google.com/p/glassdb/issues/detail?id=136
>>
>>
>> On Mon, Jan 20, 2014 at 11:40 AM, Johan Brichau <johan at yesplan.be> wrote:
>>
>>> Hi,
>>>
>>> My repository has a (large) number of objects that are no longer
>>> referenced from the persistent root but that are never garbage collected.
>>>
>>> When I do:
>>>
>>>         ClassXX allInstances
>>>
>>> I get a number of instances but when I then do for an instance i:
>>>
>>>         SystemRepository findReferencePathForObject: i
>>>
>>> The answer is that there is no path (aka 'false' as the second element
>>> in the array that is returned).
>>>
>>> Any ideas how I can investigate this?
>>>
>>> thx
>>> Johan
>>> _______________________________________________
>>> Glass mailing list
>>> Glass at lists.gemtalksystems.com
>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>
>>
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140303/b38b6037/attachment-0001.html>