[MLton-devel] MM with two mlton apps

[Stephen Weeks]

> However, I think we could do better. A first way would be to do
> (from ML, first app):
> 
> 1) call GC()
> 2) call releaseToSpace()
> 3) spawn(second app)
> 
> However, I was wondering if this is really optimal as we only need
> to call GC in case the mutator has allocated significantly since
> the last GC.
> 
> What is your opinion ?

I see two problems to be addressed, of which you mention 1.  There may
be problem of wasting time due to doing doing extra GC, but given that
you're doing it to avoid paging, I would think doing the GC is almost
always a win.  The second problem is one of memory usage -- even doing
the GC and releasing to space still holds on to a lot of unused memory
in from space.  Better would be to shrink from space after the GC so
that the ratio of heap size to live data is only 1.1, say, instead of
the usual 8.  That way, the OS won't have to page out useless parts of
from space.

So, we could add a function, MLton.GC.pack, with the following behavior.

1. collect
2. releaseToSpace
3. shrinkFromSpace

Then you could call pack and spawn.  When the parent resumes, it will
hit the limit and perform another GC very quickly and get back to the
desired heap size.

As you suggest, this could be improved by avoiding the collect if
there haven't been many bytes allocated since the last GC -- the GC
can determine this by comparing frontier and (base + bytesAllocated).
If that is small enough, then the GC could just do the shrink.

A second improvement would be to avoid doing the GC upon resumption.
To do this, we could add MLton.GC.unpack, which allocates a heap of
the desired size and translates the current heap into it.  So, you
would do

1. pack
2. spawn
3. unpack


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel