[MLton] Ongoing parallel runtime work

[Matthew Fluet]

On Sat, 19 Jan 2008, Eric McCorkle wrote:
> I've been working steadily on my efforts to implement the parallel runtime 
> system I described in earlier discussions.  The scheduler is at a point where 
> I'm comfortable adding it to subversion.  I'll have to come back and do some 
> work to implement the CML synchronization primitives, but the scheduler 
> itself, as far as I can tell, is solid (I have a randomized test program I 
> can send with it).  I already have subversion write access, but need a bit of 
> direction on what subdirectories, etc my code should go under.

The appropriate place for work-in-progress would be a subversion branch. 
Our convention has been to make branches with the name 
"on-YYYYMMDD-NAME-branch".  For subversion, you would do something like:

   svn cp -m "Making NAME branch" svn+ssh://mlton.org/svnroot/mlton/trunk svn+ssh://mlton.org/svnroot/mlton/branches/on-YYYYMMDD-NAME-branch
   svn co svn+ssh://mlton.org/svnroot/mlton/branches/on-YYYYMMDD-NAME-branch mlton.NAME-branch
   cd mlton.NAME-branch
   (* apply changes *)
   svn commit

Please do not just
   svn mkdir svn+ssh://mlton.org/svnroot/mlton/branches/on-YYYYMMDD-NAME-branch
and 'svn add'.  That completely foils seeing the difference between the 
mlton trunk and your project.  Indeed, it would be ideal that there are 
multiple commits showing the development of your project from the mlton 
trunk to its current state, rather than one massive commit that brings 
over all of your project.

It would also be very good to add a
   <src>/doc/NAME-notes
directory and a README file that accumulates some details on the project, 
how it differs from the mlton trunk, etc.

> In particular, I've done the following:

These sound like fairly extensive changes to both the runtime and the 
compiler proper.  Is all of this implemented and working, or just 
work-in-progress changes?

> In the beginning, I was planning not to do generational collection at this 
> time, but I've built things to make it easy to add.  I'm reconsidering this, 
> as supporting generational collection would make some aspects of calculating 
> the root set alot easier (the global pointers and the currently-existing 
> threads can be treated as externally-stored objects and described using type 
> signatures).  However, the price is that *all* pointers must be represented 
> with double-pointers, not just global pointers.  Does anyone have practical 
> experience/observations which can inform this decision?

Sorry, I don't have much experience to share.  But, it seems like making 
everything double-pointers would use a lot of space.  (Though, for 
parallelism, perhaps trading that space for time is a good tradeoff.)