On Mon, Jul 04, 2005 at 02:58:47PM -0700, John M McIntosh wrote:
> This could be very well an issue with the remember table holding onto  
> something large which
> is causing excessive marking activity when the incremental garbage  
> collector runs. If a full GC
> which you can invoke manually solves the problem, then it most likely  
> is the issue.

I'm not very familiar with the GC internals; in particular I've never
heard of the "remember table."  Is this used to hold onto roots (or
maybe everything) in new space that you want to keep?

A characteristic of my image is that has lots of little objects held
in a doubly linked list (actually, several doubly linked lists), and
I'm always generating more (it's a list of my activities).  Does that
seem a good prospect for triggering this scenario?

Does "Smalltalk garbageCollect" invoke the global GC?  If not, is
there a way to do so?  The direct invocations I found where in the VM
code.  As I reported, sometimes "Smalltalk garbageCollect" works, and
sometimes it doesn't.

Also, am I correct in inferring from what you say that time spent in
the garbage collector is not reported by the debug tallies?  There is
some reported GC info at the bottom, and it doesn't seem to show much
action (copied by hand from report during one of the high CPU/low
reported CPU use sessions):
**GCs**
full 0 totaling 0ms
incr 29 totalling 107ms (1.0% uptime), avg 3.0ms
tenures 0
root table 0 overflows

> 
> To confirm you need to have a linux VM that is built from the latest  
> VMMaker source to pickup
> my GC Monitor changes, then load the changeset
Is that a prebuilt VM, or do I need to build from sources?  (I can't
see it right now because I'm downloading over dial up and get a
timeout on the page).

Will the fact that I'm on Debian, or the fact that my image is in the
3.6 era, pose any problems with the changeset you mention below?

> 
> Visit my Idisk,
> 
> http://homepage.mac.com/johnmci/FileSharing.html
> 
> GCWork directory
> 
> load the JMMGCMonitor.4.cs  changeset
> 
> Then follow the instructions in
> 
> ReadMeForGCStatisticalGathering.rtf
> 
> You will find there is logic in
> GCMonitor>>calculateGoals
> to force a tenure if the mark count goes greater than 2x the  
> allocation count, usually a sign that the remember table is getting  
> too large, or causing too much marking based
>  on the objects it is looking at in oldspace.

Thanks very much.  I'll give it a try.

Also, if anyone has any insights about why my memory footprint is so
large compared to the disk files, I'd love to hear it.  Perhaps the
files saved to disk are compressed?