I have 320M of physical memory.  I managed to find the problem.  I was
creating garbage so fast that I was overflowing the root table and
incrementalGC was reverting to a fullGC.  Periodic calls to Smalltalk
garbageCollectMost solved the problem.  Time to dig out the recent thread on
this subject.

Thanks for the tip on proper use of -memory: usage.  It is hard to see any
correlation between the command line and the VM stats if you don't know it
silently eats a character.

-david

-----Original Message-----
From: Dwight Hughes
To: squeak at cs.uiuc.edu
Sent: 25/06/00 14:09
Subject: Re: GC Questions

How much actual RAM do you have - how much is available after you start
up your image? If you used -memory:10240 with a Win32 VM you will get
240MB allocated -- if you do not put a space after -memory: it gobbles
up the first character of the argument (which is in megabytes BTW, not
K).

"Pennell, David" wrote:
> 
> I have a piece of code that walks a largish (100,000 entry) B-Tree
with an
> inner loop updating a bunch of simple objects (min,max,sum on a float,
count
> (small integer)).  If the inner loop count is small, it runs very
fast.  If
> I exceed a threshold on the inner loop count, performance slows by
about
> 400:1.
> 
> The slow-down seems to correlate strongly with Full GC's, which are
running
> about 4.6 seconds each on my 500 MHz PIII (Win2k, 2.8TP, update 2158,
not
> latest VM).
> 
> - What triggers a full GC?
> - What factors impact the time to full GC?

I'm thinking the full GCs may not really be the real source of the
problem but just a symptom.

> ------------------------------------------
> Following are VM stats from before and after a couple of executions:
> 
> uptime                  19h39m21s
> memory                  251,642,216 bytes
>    old                  115,087,276 bytes (45.7%)

Note - you have about 110MB in old space -- from your command line I
assume you just wanted to allocate 10MB for the image (not really enough
for most work with a full image - the default VM allocation is 16MB and
a clean fully loaded image uses about 9MB of old memory just for
itself). I'm assuming you don't expect to have such a large image - look
for memory hogs that are being held onto. If you do not have enough
available RAM to support an image of this size, some may be being
swapped out to disk -- a full GC on an image not entirely in RAM is
painful.

>         young           119,272 bytes (0.0%)
>         used            115,206,548 bytes (45.8%)
>         free            136,435,668 bytes (54.2%)
> GCs                     323,474 (219ms between GCs)
>         full            219 in 1,023,354ms (1.0% uptime), avg 4673.0ms
>         incr            323255 in 516,920ms (1.0% uptime), avg 2.0ms
>         tenures         972 (avg 332 GCs/tenure)
> --------------------------------------------
> uptime                  19h40m10s
> memory                  251,642,216 bytes
>         old             115,090,312 bytes (45.7%)
>         young           50,624 bytes (0.0%)
>         used            115,140,936 bytes (45.8%)
>         free            136,501,280 bytes (54.2%)
> GCs                     323,729 (219ms between GCs)
>         full            221 in 1,032,505ms (1.0% uptime), avg 4672.0ms
>         incr            323508 in 517,341ms (1.0% uptime), avg 2.0ms
>         tenures         975 (avg 331 GCs/tenure)
> --------------------------------------------
> BTW - I don't think the uptime report is correct.

That was a longstanding bug in the Win32 VM (maybe other VMs too?) - but
it seems to be fixed in the latest 2.8 VM for Win32.

> I can't seem to correlate the total memory with my command line.
> I used -memory:10240 for this image activation.
> 
> Thanks,
> David
> (offline until sometime tomorrow when I get to my French office...)