[gclist] Name that hypothesis

Hans Boehm boehm@hoh.mti.sgi.com
Fri, 6 Dec 1996 13:06:22 -0800


On Dec 5, 11:34pm, Mark Tillotson wrote:

> [ To back up a hypothetical situation with a real one, I will point
>   out that I regularly use an interactive language system image of
>   some 80MB total heap, and don't get any noticeable pauses for
>   GCs (its generational, non-incremental).  In the last 20 minutes or so
>   I ran some code that allocated over 300MB of short-lived objects, and
>   1.2% of the CPU time went on GC, in about 1200 pauses of 10ms each
> ]
>

On the other hand, Barry Hayes made a number of measurements of the Xerox PARC
Cedar system for which on the order of 10% of the bytes allocated during
moderately long runs survived until the end of the run.

Anytime you read a file larger than 100Kbytes into some meory representation in
the hypothetical system you described, you will get something like 100%
promotion rate.  (This assumes essentially no temporary allocation in the
process, which is likely for a well-tuned system.)  When I was using Cedar, GC
performance tended to be most noticeable while building large in-memory data
structures, so this is not something to be ignored.  It's one of the cases that
a system should be tuned for.

Experience with my conservative generational collector suggests that you often
want to run full collections after < 10 partial collections.  (The current
default strategy is to unconditionally run a full collection every 5th GC, if I
remember correctly.  This is influenced by the fact that it's usually used with
C code, the fact that it's a conservative collector, which tends to extend
lifetimes of short-lived lifetimes somewhat, and by the simple tenuring
heuristic, which speeds up collections at the cost of extra tenuring.)

Generational collectors are often a good idea.  Sometimes the can help
tremendously.  But they probably need to adapt as much as possible.  They
certainly need to be prepared for occasional failure; the performance of full
collections also matters.

Hans


-- 
Hans-Juergen Boehm
boehm@mti.sgi.com