[MLton-devel] Re: MLton-devel digest, Vol 1 #67 - 10 msgs

[Alain Deutsch]

On Mon, 22 Jul 2002 mlton-devel-request@lists.sourceforge.net wrote:

> Message: 6
> Date: Sun, 21 Jul 2002 21:04:25 -0700
> From: Stephen Weeks <sweeks@sweeks.com>
> To: MLton@mlton.org
> Reply-to: MLton@mlton.org
> Subject: [MLton-devel] MM with two mlton apps
> 
> 
> > 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

Yes, that would be great !

--
Alain Deutsch, CTO              tel.: +33 (0)1 49 65 32 64
PolySpace Technologies          fax.: +33 (0)1 49 65 05 77
mailto:deutsch@POLYSPACE.COM    http://www.polyspace.com



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