[MLton-devel] new heap resizing approach

[Henry Cejtin]

You say that the new approach is to compute the semispace size y based on the
live amount x, but using that would require a kind of fake GC  to  cmpute  x,
wouldn't it?

You called them `Regions', but these are really cases, right?

I'm  confused  by  your conditions.  Are they just estimates?  It seems to me
that

    case 1
        L * x + y <= R

    case 2
        R < L * x
        M * x + y <= R

    case 3
        R < M * x + y

You use
    L * x + x <= R
for case 1 instead of
    L * x + y <= R
Are you thinking of using y as an estimate for x?  Clearly  it  is  an  upper
bound  This though is always going to cause y to be L times as big as the old
semispace size unless we can't fit.  Is x supposed to be the amount live from
the  previous  GC?   Then I claim that this is the wrong value to use because
you are going to be jumping around the from space during the GC.

For case 1, again,
    y = R - x
(y being the new semispace size) only makes sense if x is the  old  semispace
size.   With  that  interpretation then I agree that if we are in trouble but
not desparate than this is a reasonable size for the new semispace size.

As to case 3, here the trade off is more complex.  It is  basically  a  trade
between amount of swapping during GC and amount of swapping by the mutator.

As  to  the unmapping, I guess that case 1 is the most important, but I think
that a compilation (and I suppose run-time as well) flag to always unmap  the
old space seems desirable.

_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel