[MLton] upcoming public release

Stephen Weeks MLton@mlton.org
Tue, 2 Nov 2004 19:43:44 -0800

> > I agree that eliminating such problems would be hard.  This approach
> > would also have negative performance impact by causing the compiler to
> > keep around stuff that would otherwise be dead.
> It only keeps around state that will be relevant to the next compilation.
> True, in the case I have in mind, this state would be cached contents and
> elaboration of the Basis and whatever other libraries one wanted.

There is more that might be kept.  There are properties unrelated to
elaboration that are cleared after the pass where they are needed is
done.  We either have to figure out how to re-initialize these or we
have to hold on to the data.

> > I think it would be simpler to save the world during elaboration,
> > since that is where resumption needs to occur.
> I still have my reservations about this approach, but I see that it avoids
> the resumption issues.

Here's an improvement on my earlier approach (but it probably doesn't
address your reservations).  We could structure the elaborator so that
it builds basis checkpoints (in memory) for every N files and keeps
track of the enivornment assumptions for each checkpoint.  Then, upon
resumption, the elaborator finds the latest valid checkpoint and
starts from there, accumulating new checkpoints onto the valid prefix
of checkpoints.  The new sequence of checkpoints is saved to a world
when elaboration is done.