[gclist] GC triggering strategies

[Paul R. Wilson]

>From majordom@iecc.com Tue Mar 19 13:07:17 1996
>To: gclist@iecc.com
>cc: boehm.PARC@xerox.com
>Reply-To: gclist@iecc.com
>
>The other things to keep in mind are:
>
>1. Triggering GC based on stack height etc. makes less sense in a multithreaded
>system  (which stack?)

Right.  That's why explicit calls are more general.

>2. Providing the user with explicit calls is tricky if you want the interface
>to be independent of the collector.  For example, an incremental update
>collector doesn't trace any particular program state.

Right.  On the other hand, the "interesting" point for an incremental
update collector is often the same as for stop-and-copy.  If you perform
the flip after most of the data have died (between phases), you'll scan
your roots and start tracing stuff that doesn't lead to the garbage.

I think in general, using phase behavior works for most GC's, as long as
you opportunistically *start* the GC;  whether the tracing happens
all at once or incrementally isn't critical.

>That's not to say that there aren't situations in which these techniques are
>very useful.

Right.  Even in a multithreaded app, it's often quite clear to the programmer
where the phase boundaries are.  (E.g., after a bunch of threads synchronize
because they've solved a bunch of divide-and-conquer subproblems, or before
spawning a bunch of threads to solve new subproblems.  And sometimes, there's
just one thread that does all of the memory-intensive work, and the others
can be pretty much ignored.)