Investigating the growth and garbage of a gemstone db

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Investigating the growth and garbage of a gemstone db

GLASS mailing list
Hi,

If I want to get a better understanding which objects make up the set of ‘objects to be collected’ after an MFC, is there a way to do that?
Is there a way to get a handle on those objects or know how many of which class there are, etc?

Also, more generally, I would want to investigate the growth and contents of a gemstone database.
Trying to understand which objects are gc’ed at every MFC cycle is part of that, but I’m interested to know how to best get a view on what’s in the database without doing a ‘allClasses collect: #allInstances’ ;)

I’m a bit fuzzy… but that’s also because I’m mostly wondering how to best approach this and what strategies already exist.

Thx
Johan
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Investigating the growth and garbage of a gemstone db

GLASS mailing list
I got an email from Otto pointing me towards the class GsObjectInventory

Cool. I did not know about that class (after so many years… I feel a little embarrassed ;)
I’m going to check it out what it can report.

cheers
Johan

> On 22 Mar 2019, at 16:11, Johan Brichau <[hidden email]> wrote:
>
> Hi,
>
> If I want to get a better understanding which objects make up the set of ‘objects to be collected’ after an MFC, is there a way to do that?
> Is there a way to get a handle on those objects or know how many of which class there are, etc?
>
> Also, more generally, I would want to investigate the growth and contents of a gemstone database.
> Trying to understand which objects are gc’ed at every MFC cycle is part of that, but I’m interested to know how to best get a view on what’s in the database without doing a ‘allClasses collect: #allInstances’ ;)
>
> I’m a bit fuzzy… but that’s also because I’m mostly wondering how to best approach this and what strategies already exist.
>
> Thx
> Johan

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Investigating the growth and garbage of a gemstone db

GLASS mailing list
Johan,

I did some work on the project obex (Object Explorer for GemStone)[1]
that might apply to what you are looking for ... Obex was aimed at doing
Roassal-based visualizations, unfortunately I never found the time to
finish it up....

Anyway there were a couple of histograms (Class/instance count and
Class/Bytes) that were built using obex[2]. I was using
GsObjectInventory for some things, but also there were some new apis in
the Repository class (as of 3.4), so it is worth exploring there as well
... I was trying to be able to build partial reference tree graphs[3] to
help a developer understand what was keeping the various objects alive
without being overwhelmed by the raw data ...

Anyway if you find some of these things interesting, but don't find the
implementation obvious, I can blow the dust off some of the obex code
and share the basic algorithms that supply the raw data with you ...

If you're super interested, I am interested in reviving the obex effort
and would be willing to work together with folks to finish the obex work:)

Dale

[1] https://github.com/dalehenrich/obex
[2]
https://github.com/dalehenrich/obex/blob/master/README.md#class-instance-count-histogram
[3]
https://github.com/dalehenrich/obex/blob/master/README.md#class-instance-counts-based-on-selected-set-of-instances
On 3/23/19 12:57 AM, Johan Brichau via Glass wrote:

> I got an email from Otto pointing me towards the class GsObjectInventory
>
> Cool. I did not know about that class (after so many years… I feel a little embarrassed ;)
> I’m going to check it out what it can report.
>
> cheers
> Johan
>
>> On 22 Mar 2019, at 16:11, Johan Brichau <[hidden email]> wrote:
>>
>> Hi,
>>
>> If I want to get a better understanding which objects make up the set of ‘objects to be collected’ after an MFC, is there a way to do that?
>> Is there a way to get a handle on those objects or know how many of which class there are, etc?
>>
>> Also, more generally, I would want to investigate the growth and contents of a gemstone database.
>> Trying to understand which objects are gc’ed at every MFC cycle is part of that, but I’m interested to know how to best get a view on what’s in the database without doing a ‘allClasses collect: #allInstances’ ;)
>>
>> I’m a bit fuzzy… but that’s also because I’m mostly wondering how to best approach this and what strategies already exist.
>>
>> Thx
>> Johan
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass