[GemStone-Smalltalk] Scanning objects

Thu Mar 26 11:28:36 PDT 2015

>
> Nice work on the visualizations! (https://vimeo.com/123261640)

Thank you ! These are ideas with the help of Dale. We (Roassal) would like
to do some useful object visualizations for Gemstone, profiling code in the
repository and potentially the repository state itself. This visualizations
can work on a TODE-client-pharo-image with Roassal package. (Or on any
Pharo image including TPZ-talk package and script and good configuration...
but this is just a try for now) :)

Thanks a lot for the good explanations, it is really clear now .

There is still one thing I wonder:
The common use of that method suppose that you already have an idea of what
is the delimiting collection of objects that could have a reference (the
roots) on your objects you would like to kill.
So, supposing that you know that this or this objects should be garbage
collected, how do you know what could be the delimiting objects that have a
reference on it? In that case are you not supposed to try the scan on a
very large spectrum  ?

Thanks again a lot,

Pierre

2015-03-26 12:36 GMT-03:00 James Foster <james.foster at gemtalksystems.com>:

> Hi Pierre,
>
> Nice work on the visualizations! In GemStone (as with any Smalltalk), one
> is sometimes faced with the question, “Why is my image (or repository)
> growing?” If you are intentionally adding data to a record, then that’s
> fine, but if you are expecting a “steady-state” then growth would be
> unexpected. For example, if your application design is to remove tickets
> when they are closed, then you would expect a (fairly) stable system.
>
> Given the object graph nature of Smalltalk, things will be
> garbage-collected if they are not reachable from a persistent root (in
> Pharo it is the SmalltalkImage singleton or the SystemDictionary in
> globals; in GemStone it is AllUsers). Thus, the question, “Why is my
> image/repository growing?” has a simple answer: “Because there are objects
> that aren’t being garbage-collected!” The question, “Why aren’t these
> objects being garbage-collected?” also has a simple answer: “Because they
> are reachable from a persistent root!”
>
> This suggests the question, “What are the path(s) to some objects that I
> think should not be referenced?” That is, I’ve removed them from my master
> collection (say, OpenTickets), but they still exist in the
> image/repository. Typically what we find is that in an effort to optimize
> some lookup, we keep a cache of references. For example, I want to know
> which tickets an employee is handling. Instead of iterating over all the
> tickets (which could take more time), I have a collection of assigned
> tickets in the employee object. If I remove an object from the master
> collection, it doesn’t automatically get removed from the employee’s active
> list.
>
> By running the method
> #’findAllReferencePathsToObjects:limitObjArray:printToLog:’, you find that
> a ticket is held by a collection that is held by an employee. This brings
> you to the realization that you forgot to remove tickets from the
> employee’s active list when they are closed. That is a typical use of this
> method.
>
> James
>
> On Mar 26, 2015, at 6:10 AM, Pierre CHANSON <chans.pierre at gmail.com>
> wrote:
>
> Hi James,
>
> ok I understand know that using this method you are supposed to have a
> bunch of objects that you know you don't need to exceed in the scan.
>
> I have this very quick video to explain what I am doing, the scan method
> is used arround 2:30 https://vimeo.com/123261640
>
> So I was more in going from an object to another without limit, but I was
> not well aware of the real uses.
>
> Would you have some example of common uses with this method ?
>
> Thanks :)
>
> Pierre
>
> 2015-03-25 22:23 GMT-03:00 James Foster <james.foster at gemtalksystems.com>:
>
>> I’m not sure I understand the question. The first argument, the object
>> list, is the collection of objects for which to search. The second
>> argument, the limit collection, tells the system to stop searching
>> backwards when it reaches one of these objects. Thus, you will have an
>> answer of paths from each of the objects in the first collection to each of
>> the objects in the second collection.
>>
>> Finding all references to every object is an unusual request. What are
>> you trying to accomplish? Usually you have a handful of objects and are
>> wondering, “Why isn’t this getting garbage collected?” This method helps
>> with that.
>>
>> James
>>
>>
>> On Mar 25, 2015, at 6:14 PM, Pierre CHANSON via GemStone-Smalltalk <
>> gemstone-smalltalk at lists.gemtalksystems.com> wrote:
>>
>> Hi everyone,
>>
>> I am working with the interesting method:
>>
>> Repository>>findAllReferencePathsToObjects:limitObjArray:printToLog:
>>
>> and I actually have troubles to define the limitObjArray, how can I
>> increase it from the default one ? for example on every Objects of my
>> gemstone ?
>>
>> Thank you,
>>
>> Pierre
>> _______________________________________________
>> GemStone-Smalltalk mailing list
>> GemStone-Smalltalk at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20150326/384e9c8d/attachment-0001.html>