[Glass] Lots of seaside objects not being GCed (need gemstone advise)

[Dale Henrichs via Glass]

On 07/06/2015 02:35 PM, Mariano Martinez Peck wrote:
> While I keep searching... I have a couple of question/findins
>
> 1) ObjectLogEntry initialize DID get rid of many things while 
> ObjectLogEntry emptyLog did not.
> Former does "  ObjectQueue := RcQueue new: 100." while latter does "  
>   self objectQueue removeAll.  "
> So..could it be that in case of a RC collection, removing elements is 
> not the same as building a new collection? could the RC hold to some 
> stuff we don't want to?
Well #removeAll should get rid of everything in the queue. One thing is 
that removeAll will touch all of the objects in the object log, so the 
vm doing the #removeAll will likely have a bunch of those objects in 
it's head and depending upon exactly what you do (all other gems shut 
down, logout after doing `ObjectLogEntry emptyLog`, record and share the 
results of the mfc, and logout immediately after doing the mfc and 
before doing the reclaimAll) ...

Recording oops and running with STN_TRAN_LOG_DEBUG_LEVEL=3 will make it 
possible to find out in detail what is going on ... but do keep in mind 
that at this debug level we are recording a lot of information about all 
of the sytems operations in the tranlogs, so the size of the tranlogs 
can dramatically increase not to mention the system will run slower in 
some places because of the increased tranlog activity ...

>
> 2) Could it be that some objects get GCed ONLY after a second MFC is 
> run? I know it sounds weird, but in Pharo it was like that (not sure 
> if still)... to be really sure you had to run it 3 times (this was due 
> to #finalize and that part of GC done in 2 steps)

No, I don't think so ... if an object is kept alive after an mfc it is 
either because there is a path to the object from a persistent root or a 
gem voted the object down ... now keep in mind that if you have things 
going on in a live system, the system state is changing at each commit 
... so an mfc can see an object that is alive while a concurrent commit 
may break the last living link and by the time you look the reference is 
gone ... only when you have all gems shutdown and only your one topaz 
session is alive can you be sure that that another session isn't 
changing things "out from under you"
>
> 3) #allInstances can include instances already for GC? In other words, 
> if I run MFC and then I do #allInstances... would I get those that 
> were marked as GC (until reclaim happens)? I ask this in order to know 
> if I should run a #reclaimAll for my tests I am doing...
>
It depends upon the view that you get when you abort. The comments in 
the listInstances code do not specify whether or not possibleDead or 
deadNotReclaimed objects are excluded from the scanned objects or not, 
so presumably it is possible to pull objects to life by the vary act of 
scanning for instances "too soon" ...

It is very tricky to test these things down to the single object 
resolution, since the act of looking can skew your results ... Even 
#reclaimAll is not 100% accurate as we've made improvements to 
#reclaimAll in 3.2 and more in 3.3....

Dale