[MLton] regions

Matthew Fluet fluet@cs.cornell.edu
Fri, 1 Oct 2004 17:30:20 -0400 (EDT)


> Matthew, I'm wondering what you meant by compromising both systems.  I
> understand that they had to weaken the region analysis in order to
> allow the pointer tracing in a GC.

Yes.

> But going the other direction, it
> seems possible to me that a combined region + GC system could at least
> be safe for space, although it isn't clear to me if their combination
> achieves this.

By compromise, I simply meant that the implementation couldn't be as clean
as one system or the other exclusively.  A GC still needs to be region
aware.

> > So, one might ask whether we might do the same thing -- i.e., provide a
> > MLton.Regions structure with explicit region based memory management
> > operations, so that the programmer could use them when appropriate.  I've
> > recently thought about this question:
> >
> > http://www.cs.cornell.edu/People/fluet/rgn-monad/index.html
> >
> > Unfortunately, I think my current conclusion is that the SML type system
> > is just a little too weak to really support this option.
>
> I'm curious if you think it would be worthwhile if the typing issue
> were addressed.  That is, would the performance really be better than
> our generational GC?

I think it is as you said latter -- if you really have a program where the
stack-like disciple of regions is met, then it could beat out a GC.
That's the reason for making it programmer specified.

> > Final thoughts -- consider why one would choose region based memory
> > management.  One common arguement is that the region operations can
> > all be done in (approximately) constant time; therefore, you
> > eliminate GC pause times.
>
> I've heard this argument too, as well as other arguments that regions
> improve overall performance.  I'm not convinced by either.  Are there
> others?

You get a little bit more static reasoning about lifetimes (again, in some
certain cases).  I've heard that the security guys can be swayed by this
sort of argument: read the user's password into a region allocated buffer,
check it, then leave the region.  Now you know the password has been
purged from memory without it hanging around for the GC to find it.

Again, I think that regions are the right solution for a small class of
problems.