[Shootout-list] Missing programs and score calculation (Was:

[Stephen Weeks]

> Indeed, I am interested (where's that 64 bit MLton? :)

Yeah yeah yeah :-).  We're still fighting to get the current release
out the door, and Cygwin as usual is causing problems.  64-bit MLton
is four to six months away.

> As I understand it, the MLton system has its own
> stack and uses a generational compacting collector,

Yes, although the generational collector isn't used unless memory is
tight, since it does cost.

> > For example, MLton is quite careful to
> > preserve variable lifetimes and make the liveness information
> > available to the runtime.
> 
> How and why?
> 
> Clearly, on the 'why' front, this allows eliminating
> more garbage. However, otherwise the main impact would
> be earlier execution of finalisers (and later execution
> of initialisers).
>
> I could probably implement this too, but it would cost,
> and I'm not sure what the real benefits are.. I'm interested
> in your view on that.

The most important reason is so that the programmer can have a clear
model of memory usage that he can understand in terms of the source
language.  The idea is that the compiler shouldn't keep variables
alive longer than they are live in the source program.  This is often
called "safe for space" or "space safety".  I view space safety as an
essential property of a garbage-collected language, since without it
there will be space leaks that are almost impossible to localize and
fix (if the programmer has no guarantee from the compiler, what can he
do?).  And one will never be sure whether there is some leak that
hasn't been hit yet or if some small change to the program will cause
the compiler to introduce a leak.  This is even worse then programming
in C, since at least in C one has the ability to explicitly free
memory.

It does cost, and requires care in many optimization passes to avoid
increasing lifetimes of variables too much.  But the benefit to
programmers is well worth it.