[GemStone-Smalltalk] Scanning objects

Mon Apr 6 10:38:56 PDT 2015

Yes it is quite powerful ! Thanks again for your help James, I will give
some other tries on this scan soon.

Pierre

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

> As mentioned earlier, there is always an ultimate root, so the question of
> picking a stoping point is really not so important. If you leave it out
> then the reference chain will always start with the following:
> AllUsers->aUserProfile->aSymbolList->aSymbolDictionary->aSymbolAssociation
> From the SymbolAssociation you know the name of the global that is in the
> reference path, and knowledge of your domain should be enough to get the
> idea (that along with the classes of the instances in the path). Yes, it
> will try to scan a large space, but that is the nature of this sort of
> query—it is just expensive (but very powerful).
>
> James
>
> On Mar 26, 2015, at 11:28 AM, Pierre CHANSON <chans.pierre at gmail.com>
> wrote:
>
> 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/20150406/0ba0a1d2/attachment.html>