[Glass] Lots of seaside objects not being GCed (need gemstone advise)
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Mon Jul 6 15:34:10 PDT 2015
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....
More information about the Glass