[gclist] Finalizers & Reference counting.

[Nick Barnes]

At 2002-08-30 23:10:42+0000, David Chase writes:
> At 07:56 AM 8/30/2002 -0400, Jerrold Leichter wrote:
> >This whole discussion does bring up an interesting point, however.  Some
> >programs - compilers are a great example - go through phases with the
> >property that:
> >
> >        a)  Each phase allocates and manipulates a significant amount of
> >                memory, much of which remains live throughout the phase;
> >
> >        b)  Much of the memory allocated in a phase goes dead when the
> >                phase ends.
> >
> >(In many cases, the "much" memory is actually identifiable at the point of
> >allocation.)
> 
> In my experience, compilers tend to gave generational collectors
> a hard time, especially when compiling a large number of files.
> The first big file that gets compiled stuffs a lot of crud into
> old space, and then it lingers for a lot longer than it ought to.

In my experience with compilers with GC, there is a major benefit to
generational collection with many generations (e.g. 4-6, a dynamic
number being best), and it is a very good idea for the compiler to
provide hints to the GC, based on compilation phases.  This can be as
simple as "collect now", or more sophisticated than that (the next
level of sophistication being things like "don't collect yet" and
"don't promote this stuff yet").

For the MLWorks runtime, our main test application was the MLWorks
compiler compiling the whole of the MLWorks system.

>   GCTime gct = gc.getTimeStamp();
>   ...
>   // Insert compiler phase here.
>   ...
>   gc.collectYoungerThan(gct);
> 
> A more precise interface would be
> 
>   gc.collectBetween(gct_begin, gct_end);
> 
> Of course, an implementation is free to take these as a mere hint,
> and either not collect, or collect everything.

This sort of thing is good.  Some sort of "don't promote" interface is
also useful.

Nick B