How to make sure objects get garbage collected? 
Author Message
 How to make sure objects get garbage collected?

Our application (ezboard.com) relies on a big cache of objects in
memory to minimize I/O which improves performance.

We have 4 basic domain objects that we cache at ezboard.com - boards,
forums, topics and users.

Every 10 minutes, we analyze what objects have not been "touched"
within a certain time period and those that are older than our allowed
threshold are removed from the cache.

We also have a function that will clear all the objects out of the
cache.

What we've noticed is that even when clearing all the objects out of
the cache, the memory recovered is never as good as if we kill the
image and restart.

So my question is what could be causing this?  Is there a way to check
what objects might still be in memory?  Ideally we could take a
snapshot of all objects at initial start up, then compare that to
after we clear all caches to see that they are equal.

Our images typically hold about 400M of data.

Thanks for any assistance.



Tue, 18 Oct 2005 09:13:13 GMT  
 How to make sure objects get garbage collected?

Quote:
>What we've noticed is that even when clearing all the objects out of
>the cache, the memory recovered is never as good as if we kill the
>image and restart.

How do you measure this? For example, VW's ServerMemoryPolicy tends to
keep memory allocated on the OS level, even when it doesn't need it
right away. So first priority would be to make sure that this is a real
'loss' of memory.

Quote:
>So my question is what could be causing this?  Is there a way to check
>what objects might still be in memory?  Ideally we could take a
>snapshot of all objects at initial start up, then compare that to
>after we clear all caches to see that they are equal.

A simple first start would be to make a tally along the lines of 'Object
allSubclasses collect: [:each | each -> each instanceCount]' on a fresh
start and after the snapshot, then compare them. I've been hunting for
leaks several times, and there doesn't seem to be a silver bullet.

(I just tested whether #instanceCount was indeed right. To my surprise:
ObjectMemory instanceCount -> 3. And I thought it was a singleton?)

--

GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B
Cogito ergo evigilo



Tue, 18 Oct 2005 09:37:17 GMT  
 How to make sure objects get garbage collected?


Quote:
>What we've noticed is that even when clearing all the objects out of
>the cache, the memory recovered is never as good as if we kill the
>image and restart.

>So my question is what could be causing this?  

One possibility is that some of the cached objects are very
long-lived, and are eventually moved into perm space (or equivalent).
They will not be reclaimed until you do a full GC. If this is indeed
what is happening, then you may be able to adjust the sizes of the
various memory spaces and the tenuring policies in order to keep
objects from getting prematurely tenured.

Hope this helps,

  -Anthony
--
PGP key at http://www3.sympatico.ca/anthony.lander
3FF8 6319 CADA 2D21 03BB 175F 3382 822A 502F AE80



Tue, 18 Oct 2005 09:45:03 GMT  
 How to make sure objects get garbage collected?

Quote:

> (I just tested whether #instanceCount was indeed right. To my surprise:
> ObjectMemory instanceCount -> 3. And I thought it was a singleton?)

Not quite, it is a snapshot of memory statistics. Try

  ObjectMemory current == ObjectMemory current

Reinout Heeck
-------------
Soops - Specialist in object technology.
http://www.soops.nl/

---------------------------------------------------------------------
Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).
Gebruik door anderen is niet toegestaan. Indien u niet de"
geadresseerde(n) bent wordt u verzocht de verzender hiervan
op de hoogte te stellen en het bericht te verwijderen.
Door de elektronische verzending kunnen aan de inhoud van
dit bericht geen rechten worden ontleend.
---------------------------------------------------------------------
This e-mail message is intended to be exclusively for the addressee.
If you are not the intended recipient you are kindly requested not to
make any use whatsoever of the contents and to notify the sender
immediately by returning this e-mail message. No rights can be
derived from this message.
---------------------------------------------------------------------



Tue, 18 Oct 2005 16:18:55 GMT  
 How to make sure objects get garbage collected?

Quote:

> One possibility is that some of the cached objects are very
> long-lived, and are eventually moved into perm space (or equivalent).

I think that objects never move to perm space automatically, you have
tell the system to do so explicitly e.g. by doing a perm-save.
Afaik all other spaces are under the regime of the  garbage-collector.

Please educate me if I'm wrong.

--
Reinout Heeck
-------------
Soops - Specialist in object technology.
http://www.soops.nl/

---------------------------------------------------------------------
Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).
Gebruik door anderen is niet toegestaan. Indien u niet de"
geadresseerde(n) bent wordt u verzocht de verzender hiervan
op de hoogte te stellen en het bericht te verwijderen.
Door de elektronische verzending kunnen aan de inhoud van
dit bericht geen rechten worden ontleend.
---------------------------------------------------------------------
This e-mail message is intended to be exclusively for the addressee.
If you are not the intended recipient you are kindly requested not to
make any use whatsoever of the contents and to notify the sender
immediately by returning this e-mail message. No rights can be
derived from this message.
---------------------------------------------------------------------



Tue, 18 Oct 2005 16:23:25 GMT  
 How to make sure objects get garbage collected?

Quote:

> So my question is what could be causing this?  Is there a way to check
> what objects might still be in memory?  Ideally we could take a
> snapshot of all objects at initial start up, then compare that to
> after we clear all caches to see that they are equal.

Have a look at "Memory Diagnostics" in
http://ftp.sunet.se/pub/lang/Smalltalk/st80_vw/memorydi.st
or in
http://wuarchive.wustl.edu/languages/smalltalk/Smalltalk/st80_vw/00_I...

It's an old one and I don't now if it's included in any of the current
Smalltalk distributions but it might do exactly what you where asking
for.

Sascha



Tue, 18 Oct 2005 16:51:53 GMT  
 How to make sure objects get garbage collected?

Quote:
>Not quite, it is a snapshot of memory statistics. Try

>  ObjectMemory current == ObjectMemory current

Thanks. Methought it was a reification of the object memory.

--

GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B
Cogito ergo evigilo



Tue, 18 Oct 2005 16:57:57 GMT  
 How to make sure objects get garbage collected?

Quote:

>So my question is what could be causing this?  Is there a way to check
>what objects might still be in memory?  Ideally we could take a
>snapshot of all objects at initial start up, then compare that to
>after we clear all caches to see that they are equal.

>Our images typically hold about 400M of data.

>Thanks for any assistance.

In VW you may want to check out the ReferencePathCollector which should be
able to sum the sizes of arbitrary object graphs you specifiy, or count the
number of objects in a graph.  This may assist you in finding clues as to
where the problem may be.

Ian

---
http://www.upright.net/ian/



Tue, 18 Oct 2005 23:42:30 GMT  
 How to make sure objects get garbage collected?


Quote:

>> One possibility is that some of the cached objects are very
>> long-lived, and are eventually moved into perm space (or equivalent).

>I think that objects never move to perm space automatically, you have
>tell the system to do so explicitly e.g. by doing a perm-save.
>Afaik all other spaces are under the regime of the  garbage-collector.

Sorry. Meant old space, not perm space.

My point, however, is that there might be a significant delay between
the time objects are removed from the cache and when the memory is
actually reclaimed, depending on the size of the spaces, and the
tenuring policy.

  -anthony
--
PGP key at http://www3.sympatico.ca/anthony.lander
3FF8 6319 CADA 2D21 03BB 175F 3382 822A 502F AE80



Wed, 19 Oct 2005 01:41:51 GMT  
 How to make sure objects get garbage collected?
You can use "SystemAnalyzer showSystemHistogram" from Advanced Tools before
and after and look for differences. Then, after you identify the class(es)
of the culprits, you can try to hunt the persistent instances (with
allInstances) and then check reference paths to them.

If you have proxies in your image you should first fix the statistics
gathering code, as well as the reference path collector to not fault them
(by using reflection (#_object:...) primitives from Context instead of
direct access)

Cheers,

Florin


Quote:
> Our application (ezboard.com) relies on a big cache of objects in
> memory to minimize I/O which improves performance.

> We have 4 basic domain objects that we cache at ezboard.com - boards,
> forums, topics and users.

> Every 10 minutes, we analyze what objects have not been "touched"
> within a certain time period and those that are older than our allowed
> threshold are removed from the cache.

> We also have a function that will clear all the objects out of the
> cache.

> What we've noticed is that even when clearing all the objects out of
> the cache, the memory recovered is never as good as if we kill the
> image and restart.

> So my question is what could be causing this?  Is there a way to check
> what objects might still be in memory?  Ideally we could take a
> snapshot of all objects at initial start up, then compare that to
> after we clear all caches to see that they are equal.

> Our images typically hold about 400M of data.

> Thanks for any assistance.



Wed, 19 Oct 2005 08:07:56 GMT  
 How to make sure objects get garbage collected?
Hello

    First of all, I would make sure that you examine the release method of
all the classes that you store in the cache and make sure that it sets all
of its instance variables to nil.

    Second you could add tracing to the inialize-release methods of all the
items that you store in the cache, and find it when (if ever) some of the
objects are executing their release methods, then find the ones that didnt
excute the release and see what is interesting about them.

    I would hazard a guess that all the references between the cached
objects are not being freed, resulting in circular garbage which will not be
reclaimed until later down the road, or possibly never if they are still
reachable from a system root object.

    Regards,
    Jordan


Quote:
> Our application (ezboard.com) relies on a big cache of objects in
> memory to minimize I/O which improves performance.

> We have 4 basic domain objects that we cache at ezboard.com - boards,
> forums, topics and users.

> Every 10 minutes, we analyze what objects have not been "touched"
> within a certain time period and those that are older than our allowed
> threshold are removed from the cache.

> We also have a function that will clear all the objects out of the
> cache.

> What we've noticed is that even when clearing all the objects out of
> the cache, the memory recovered is never as good as if we kill the
> image and restart.

> So my question is what could be causing this?  Is there a way to check
> what objects might still be in memory?  Ideally we could take a
> snapshot of all objects at initial start up, then compare that to
> after we clear all caches to see that they are equal.

> Our images typically hold about 400M of data.

> Thanks for any assistance.



Sun, 23 Oct 2005 05:26:21 GMT  
 How to make sure objects get garbage collected?

Quote:

> Hello

>     First of all, I would make sure that you examine the release method of
> all the classes that you store in the cache and make sure that it sets all
> of its instance variables to nil.

>     Second you could add tracing to the inialize-release methods of all the
> items that you store in the cache, and find it when (if ever) some of the
> objects are executing their release methods, then find the ones that didnt
> excute the release and see what is interesting about them.

>     I would hazard a guess that all the references between the cached
> objects are not being freed, resulting in circular garbage which will not be
> reclaimed until later down the road, or possibly never if they are still
> reachable from a system root object.

The VW garbage collector reclaims cyclic garbage.  Cycles within new
space will be reclaimed by a scavenge.  Cycles in new and old space will
be reclaimed once an incremental collection cycle has completed.

- Show quoted text -

Quote:

>     Regards,
>     Jordan



> > Our application (ezboard.com) relies on a big cache of objects in
> > memory to minimize I/O which improves performance.

> > We have 4 basic domain objects that we cache at ezboard.com - boards,
> > forums, topics and users.

> > Every 10 minutes, we analyze what objects have not been "touched"
> > within a certain time period and those that are older than our allowed
> > threshold are removed from the cache.

> > We also have a function that will clear all the objects out of the
> > cache.

> > What we've noticed is that even when clearing all the objects out of
> > the cache, the memory recovered is never as good as if we kill the
> > image and restart.

> > So my question is what could be causing this?  Is there a way to check
> > what objects might still be in memory?  Ideally we could take a
> > snapshot of all objects at initial start up, then compare that to
> > after we clear all caches to see that they are equal.

> > Our images typically hold about 400M of data.

> > Thanks for any assistance.

--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd


Mon, 24 Oct 2005 02:46:42 GMT  
 How to make sure objects get garbage collected?

Quote:

>     I would hazard a guess that all the references between the cached
> objects are not being freed, resulting in circular garbage which will not be
> reclaimed until later down the road,

AH, circular garbage. My favorite.
Now if A refers to B and B refers to A. Will A & B get garbaged collected?

That depends on the algorithm used to do the GC work. In *all?*
smalltalk systems, not true for some other languages, hence the
confusion, the GC algorithms do handle the circular reference case.

Thus at some point in the future A & B will get GCed. Failure for A & B
to get GCed is because something that isn't garbaged is referencing
them. Also as eliot points out "when" in the future is dependent on
which GC is needed to run to do the GC work.

So when disposing of a huge woven structure of objects, you *may* only
need to break the (one hopefully) link that gets you there. Versus
breaking links through out the structure, that is needless work.

IE Forgetting about a dictionary. It is way cheaper to nil out that
instance variable that points to the dictionary than nilling out all
the entries in the dictionary, then forgetting about the dictionary
because you think that is easier on the GC logic, or because you've
always done that in C++.

So if you've got object B after doing a full global GC (which includes
perm space) and you don't think you should have object B, then you've a
release problem...



Mon, 24 Oct 2005 04:35:43 GMT  
 How to make sure objects get garbage collected?
Yes, they handle the circular reference case, but only in the cases where
all references are garbage.

But the scavenging will be delayed at least 1 generation ,and possibly more,
hence my suggestion.

It is possible that in Vanchaus case he has a live object that is pointing
to the subobjects in the cache, which would need to be handled using a
mechanism other than release;hence my sugg for tracing...

Jordan



Quote:

> >     I would hazard a guess that all the references between the cached
> > objects are not being freed, resulting in circular garbage which will
not be
> > reclaimed until later down the road,

> AH, circular garbage. My favorite.
> Now if A refers to B and B refers to A. Will A & B get garbaged collected?

> That depends on the algorithm used to do the GC work. In *all?*
> smalltalk systems, not true for some other languages, hence the
> confusion, the GC algorithms do handle the circular reference case.

> Thus at some point in the future A & B will get GCed. Failure for A & B
> to get GCed is because something that isn't garbaged is referencing
> them. Also as eliot points out "when" in the future is dependent on
> which GC is needed to run to do the GC work.

> So when disposing of a huge woven structure of objects, you *may* only
> need to break the (one hopefully) link that gets you there. Versus
> breaking links through out the structure, that is needless work.

> IE Forgetting about a dictionary. It is way cheaper to nil out that
> instance variable that points to the dictionary than nilling out all
> the entries in the dictionary, then forgetting about the dictionary
> because you think that is easier on the GC logic, or because you've
> always done that in C++.

> So if you've got object B after doing a full global GC (which includes
> perm space) and you don't think you should have object B, then you've a
> release problem...



Mon, 24 Oct 2005 06:37:42 GMT  
 How to make sure objects get garbage collected?
Actually to furthur clarify what I think would happen in a normal smalltalk
system is:

Assume you had an Object "MessaageThread" (MT)

MT has an instance variable "messages" which is a collection.

The collection stores many "Message" objects which contain a large amount of
data.

Now, assume that MessageThread has circular references among other objects
that ultimately get GC'd.
After severl generations (at least 2) MT gets GC'd and frees up the the
collection.

On the next generation the collection is GC'd and frees up the large Message
objects.

On the next generation the Message objects get GC'd.

So it could be some # of generations before you see them all get GC'd,
depending on version and collector ...
So it seems to me that if not only the release methods nulled out the
objects , as well as nulling out the collections etc that would reduce the #
of generations in order to collect the garbage...

Jordan

Quote:
> Yes, they handle the circular reference case, but only in the cases where
> all references are garbage.

> But the scavenging will be delayed at least 1 generation ,and possibly
more,
> hence my suggestion.

> It is possible that in Vanchaus case he has a live object that is pointing
> to the subobjects in the cache, which would need to be handled using a
> mechanism other than release;hence my sugg for tracing...

> Jordan




> > >     I would hazard a guess that all the references between the cached
> > > objects are not being freed, resulting in circular garbage which will
> not be
> > > reclaimed until later down the road,

> > AH, circular garbage. My favorite.
> > Now if A refers to B and B refers to A. Will A & B get garbaged
collected?

> > That depends on the algorithm used to do the GC work. In *all?*
> > smalltalk systems, not true for some other languages, hence the
> > confusion, the GC algorithms do handle the circular reference case.

> > Thus at some point in the future A & B will get GCed. Failure for A & B
> > to get GCed is because something that isn't garbaged is referencing
> > them. Also as eliot points out "when" in the future is dependent on
> > which GC is needed to run to do the GC work.

> > So when disposing of a huge woven structure of objects, you *may* only
> > need to break the (one hopefully) link that gets you there. Versus
> > breaking links through out the structure, that is needless work.

> > IE Forgetting about a dictionary. It is way cheaper to nil out that
> > instance variable that points to the dictionary than nilling out all
> > the entries in the dictionary, then forgetting about the dictionary
> > because you think that is easier on the GC logic, or because you've
> > always done that in C++.

> > So if you've got object B after doing a full global GC (which includes
> > perm space) and you don't think you should have object B, then you've a
> > release problem...



Mon, 24 Oct 2005 07:03:47 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Module gets garbage collected; its globals become None

2. objects that won't be garbage collected (VW 2.0)

3. Garbage collecting C++ objects?

4. A garbage collector which won't collect

5. view not garbage collected

6. Does VW really garbage collect circular structures ?

7. Garbage Collecting too much

8. Garbage collect

9. garbage collecting the trail

10. Garbage collecting names in Prolog

11. Garbage collect in GCL

12. garbage collecting streams

 

 
Powered by phpBB® Forum Software