On Tue, 29 Jan 2002, Tim Rowledge wrote:

> Scott A Crosby <crosby at qwes.math.cmu.edu> is claimed by the authorities to have written:
>
> > Quick summary:
> >   The default paramaters for the GC are a poor choice for RAM-rich modern
> > computers. A 3x performance gain on GC is obtainable, if you're willing to
> > dedicate RAM to squeak. (My desktop has 768, so I think nothing of running
> > with 100-500mb)

> Well lucky you; my machines don't have that size memory and in fact my
> main machine doesn't even use virtual memory. PDAs, embedded devices,
> network computers and so are likewise memory limited. Let's remember
> that before leaping to any changes.

I went from 256 to 768 for $80, 4 months ago.

> Which is of course why those parameters are settable. Maybe some startup
> code to work out sensible machine defaults wouldbe a good idea. VW has
> allowed gc tuning for years - actually over a decade - with exquisitely
> precise policy capabilities.
>
> Almost nobody ever uses them :-(
>
> Almost everybody complains that the defaults don't work.
>

Heh, perhaps it would be good for it to remark, on the profiling page, a
notation that ``your program uses excessive time in GC, have you
considered setting your GC paramaters to:  .....''

Having them set dynamically based on how much RAM you are dedicating to
squeak and based on some menu item is this image a:
    'high latency' 'mid-latency' or 'low-latency'
and have it autodetect if its a
    'small <20mb'
    'medium 30-70mb' 'large 100-200mb' or 'very large >300mb' image.

This might help it scale to larger images in a more user-friendly way.
Have the profiler spit out suggestions if it thinks GC time is excessive.
That way they won't be missed.

> I'm not at all certain that the current Squeak memory system is really
> suited to huge memories. I can't help thinking that at least one more
> generation would be a good idea, along with perhaps a space for large
> binary (non-reference-containing) objects.

I've thought over that some.. I'm not sure where an extra generation
helps. It introduces an extra range check into every write. You'd want to
use conservative approximations.

I can see how storing large binary objects externally (through malloc or
something similar) would work, primarily, it would save them from being
moved in a compaction.

--

A lot depends on what the actual runtime statistics are like for the
different stages of GC.  I shold examine these numbers sometime. Is GC a
signifigant problem? (Lets wait for both BC and my methodcache before
answering that question.)

Really, whats probably needed eventually is dynamic feedback with the
interpreter? If you can tell, based on where the allocation occurs, the GC
behavior of the object, you can be more clever with allocation policies.

Eh.. I'm not going to touch anything, unless it seems really broken, until
BC *and* my new method cache *and* the root table overflow are in a VM I
can benchmark and profile and see the costs of GC, or whatever else is a
signifigant performance issue.)

If someone has tried integrating these and has a linux image with all of
the above that can generate a valid VM, I'd appreciate a copy of
image&build tree. If the GC is bad or there are some other performance
problems, I might have time to do some work on it by V4. Has the VMMaker
tree stabilized?

The other question is, what is the hoped-for future of squeak? Something
intended to be an applications-development platform, with 100mb images, or
something intended to run on handhelds and portables?

Scott