[MLton] Parallel Runtime System

[Matthew Fluet]

Eric McCorkle wrote:
> As part of my graduate work, I'm now working on a standalone runtime for 
> concurrent functional languages.  My goal is to provide a compact, 
> highly-parallel scheduler and memory manager which can be used as a 
> runtime for languages like Standard ML.  I'm hoping to tie this system 
> into MLton as an alternate runtime (if nothing else, to test other ideas 
> I'm investigating, but I'd be more than happy for others to use it too).

Sounds like a cool project.  One tough problem is making 'portable' 
runtime systems -- in the implementation of a high-level language, the 
compiler and runtime system are usually tightly integrated.

> I'm interested in the following:
> * Anything I should know about how MLton allocates frames (I'm assuming 
> you heap-allocate frames, of which I'm almost 100% certain, but if I'm 
> wrong, let me know!)

MLton heap allocates entire stacks, not individual stack frames.  When a 
computation is about to overflow its stack, a GC is initiated, which 
allocates a new (larger) stack and copies the computation to the new stack.

Jake Donham was working on a parallel GC (although believe that he 
abandoned the project):
   http://mlton.org/pipermail/mlton/2007-January/029500.html

> * Does MLton use safe-points, and if not, what would it take to add them?

Yes, MLton uses safe-points.  Every function that enters the runtime (in 
particular, calls to GC_collect) ensures that all live ML variables are 
allocated on the ML stack.

> * How exactly do I start an MLton program (at the low level), what 
> scheduler hooks do I need to provide, and what garbage 
> collection/allocation hooks do I need?

See  include/{c-,x86-,}main.h  in the sources.  That corresponds to the 
initial main function.

As to what you need to provide, pretty much everything from  runtime/gc
   in the sources is what the compiler expects from the garbage 
collector.  Obviously, GC_collect is the 'big' function that programs 
call, but there are a lot of other dependencies on the layout of data, 
location of the heap frontier pointer, etc.