[MLton-devel] new heap resizing approach

[Stephen Weeks]

> 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?

As we have always done, we use the live amount from the previous GC as
an estimate of the live amount for the current GC.

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

Yes.  (region = interval of integers.  no connection to ML Kit regions)

> I'm  confused  by  your conditions.  Are they just estimates?

x0 and x1 are constants, determined by the desired live ratio (L = 8)
and the minimum live ratio (M = 1.25).  Using the previous live (x),
we can determine which of the three cases applies.

> Is x supposed to be the amount live from the previous GC?  

Yes.

> For case 1, again,
>     y = R - x

You mean case 2?

> (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.

Here the idea that if y = R - x, then x + y = R.  That is, we can do a GC that
from an old space of size y that collects x live data.  Of course x is a guess
(it is the old live data size) which is why we have the slop.  I'm not sure if
I'm getting your point.  It doesn't hurt us if we have more memory mapped than R
as long as we free the old space when the GC is done.

> 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.

Agreed.  I have no experience with this case, and the 1.25 comes from the
changes that the PolySpace guys made.

> 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.

I'd rather not, since that flag is only meaningful with the current GC, and will
be meaningless with the other GCs that we are moving to.

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