Congratulations...

[Roland Olsson]

to a stable compiler and run-time system. I have now run a variety of
MLton compiled programs with a total run time of more than 72 hours and
found that they are more stable than corresponding programs compiled with
SML/NJ. In fact, I haven't seen any crash at all so far with MLton,
whereas I have space leaks and other nasty problems like segmentation
faults and bus errors with SML/NJ.

However, there were four bugs in the compiler that I had to work around,
which was quicker and easier for me than to report the bugs to you and
wait for them to be fixed. The first three were easy, but the last one
with a message like

Bug: value primApply type error

was difficult to work around. The cause turned out to be a function
converting a sorted vector to a splay tree with the bug only manifesting
itself when each element in the vector had a very complex data type.

The biggest performance problem with MLton executables is the garbage
collector which should be rewritten to be generational. The current memory
management requires almost twice as much RSS as SML/NJ and Harlequin
MLworks.

Also, the compilation process is memory consuming, which may be
unavoidable when doing whole-program analysis. I had to use the
-no-polyvariance -flatten and -inline flags to cut down the memory
consumption of MLton itself even when using the SML/NJ compiled version
since it otherwise required about 1GB RAM to compile my sml code.


These are minor problems though. Overall, MLton is very valuable.

Cheers,

Roland Olsson
Associate Prof.
Chalmers