[MLton-devel] new heap resizing approach

[Stephen Weeks]

> Ok, but please send me mail when things are checked in on this.  Also I'm
> curious as to what the bug was.

The bug was that the GC was not able to allocate enough space for to space, so
it backed off to trying some multiple of the live amount seen on the previous
GC.  Unfortunately it didn't try to ensure that to space was at least as large
as from space, which it should always do.  Hence, there was a very small to
space, and the GC died during a forward, running out of space.

I'm reworking stuff so that the code is much cleaner.  Here's my current
approach.  

For computing the semispace size (y) based on the live amount (x), there are
three regions of interest for x.

Region 1
	The semispace will easily fit in memory with the live ratio (L) and
	there will be enough space to do a GC in memory, which requires having
	the entire old space + the amount of live data in memory.

Region 2
	The semispace will not fit into memory with the live ratio, but there
	is still enough space that we can hope to do the GC in memory if
	we use a smaller live ratio.

Region 3
	Trying to do the GC in memory would require too small of a live ratio,
	so we're gonna page.  Use a small live ratio to keep the working set
	small. 

In math, here it is

L = live ratio (e.g. 8)
M = live ratio min (e.g. 1.25)
R = amount of RAM, times some slop factor (e.g. 0.8)
x = live amount
y = semispace size

x0 = R / (1 + L)
x1 = R / (1 + M)

Region 1.  if  0 < x <= x0, then y = L * x
Region 2.  if x0 < x <= x1, then y = R - x
Region 3.  if x1 < x      , then y = M * x 

In region 1, we use our desired live ratio.  In region 2, the semispace size
decreases as the heap size increases, because we want to be able to do the GC in
memory.  In region 3, we're in trouble, so we just keep a little extra working
space.  If you draw the graph, plotting semispace size (y) against live data
size (x), hopefully it will make some sense.  The ram slop is there so that we
have space to grow the heap without paging (as long as it doesn't grow too
much).

As to unmapping old space, there are several conditions under which it will be
unmapped
	1. if the new space is larger than R/2, since keeping it around might
		cause paging.
	2. if the new space is larger than old space, since we won't be able
		to use old space for the next GC
	3. if the live ratio after the gc is pretty high and hence we're going
		to try to grow the semispace for the next GC
		
I'm still experimenting with all of this.

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