[Glass] instances not being garbage collected?

[Thierry Thelliez]

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/20140301/8724961a/attachment.html>