[MLton] stack-allocated references

[skaller]

On Wed, 2007-02-28 at 23:23 -0600, Matthew Fluet wrote:
> skaller wrote:
> > On Wed, 2007-02-28 at 21:56 -0500, Jake Donham wrote:
> > 
> >> Is there any limit to the size of a stack frame? 
> > 
> > Of course there is a bound per program, which a whole
> > program analyser like Mlton can no doubt be coaxed into calculating,
> > and of course there is no universal bound for all programs.
> 
> Indeed, MLton does calculate the maximum frame size 
> (gcState.maxFrameSize) for every program.
> 
> While there is no universal bound on the live data at a program point, 
> one could fix a maximum frame size (for all programs) by rewriting 
> functions to aggregate live data that exceeded the stack size and 
> allocate it on the heap.  I.e., rather than spill to a mutable stack 
> slot, spill (multiple) temporaries to an immutable heap object, and use 
> just one stack slot to point to the object.
> 
> This trades more allocation of immutable objects for a smaller mutable 
> stack frame, which might be the right trade off in a real-time setting.
> (Though I doubt that any reasonable ML program yields stack frames of 
> such size as to make a significant change in the real-time bound.)

In fact if you do this, you can guarantee that except at 
frame initialisation time, the stack is always immutable.

Mutable store is a bitch for parallel collection .. do we
really need it?

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net