Re: how to tune generational collector in work3?

["Juris Kalnins" <juris@...>]

On Tue, 01 Jun 2010 20:49:36 +0300, Roberto Ierusalimschy  
<roberto@inf.puc-rio.br> wrote:

> > Possible change would be to use gcpause to trigger small gc,
> > and 100+gcpause to trigger full gc. I.e.
> >
> >     if (g->totalbytes > g->lastmajormem/100 * (100 + g->gcpause))
> >       g->lastmajormem = 0;  /* signal for a major collection */
> >
> > This would keep the meaning more or less consistent in both modes and
> > avoid the pathological case with fullgc when gcpause < 100.
> >
> > I tried and it seems to work well.
>
> I am afraid I missed the "base code" where you did the above change.
> Are you proposing this change on top of the original w3 code? (That
> is, with the original definition of stddebt, etc.?)

Sorry for being too brief. Yes, original work3 plus
the ~bitmask(GCSpause) fix. The reasoning was that:

1) If gcpause <= 100, then the condition
    g->totalbytes > g->lastmajormem/100 * g->gcpause
  will trigger almost always. So only values >= 100 are
  "interesting" here
2) GCdebt should be initialised to something that does not
  exceed (g->lastmajormem/100 * g->gcpause - g->totalbytes)
  much, otherwise memory will be allocated way past the
  gcpause threshold before triggering the collection.

> Maybe instead of the "100+gcpause" we should add another parameter
> for this? Something like "gcpauseminor" and "gcpausemajor"?

Hmm... currently there are 2 tunable parameters:
pause - how much to allocate before starting new full collection.
  it would be really good if in both modes this value
  had the same meaning, so that it would be possible to keep
  about the same memory usage in both modes without having to
  change "pause" and run "restart"
stepmul - how much to do in a single incremental step

gcpauseminor feels more like the non-tunable GCSTEPSIZE, by controlling
how often the minor collection will run.

Is there a situation where user would like to specify gcpauseminor?
That is, where a well chosen default would be inappropriate?

Such parameter would be interesting if the minor collections
could run during the GCSpause of the incremental collector. But then
again, setting gcpauseminor small wouldn't really limit maximum
running time of the minor collection.

And thank you for the explanation of barriers.