[Glass] instances not being garbage collected?

[Johan Brichau]

Hi Dale,

The objects that stick around are not part of any indexes. But I would interested to know what to do with such references too at some point.
However, right now, I have the issue with a set of objects of different classes, which are referencing each other (which is logical) but their transitive closure is large.

I am playing around in a copy of the extent, so it went through a mfc/backup/restore and several mfc already afterwards with no seaside gems running.

I fiddled around some more, nilling some instance variables part of those objects to try to 'cut some references' to prune them.
Some of them are now gone but I still have a long way to go to get the real stuck object(s).

If you think of any places I should search, let me know, in the meantime I hope that I will be able to prune the objects enough to get a better idea.

Johan

On 20 Jan 2014, at 22:47, 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
>