[MLton] profiler bug?

[Lukasz S Ziarek]

In an atempt to get total allocation numbers to compare tuple flattening
to no tuple flattening (droping the flatten and the three localflatten
passes in MLton) I have come across the following behavoir when using
the profiler. This is a clean version of mlton checked out of cvs
yesterday afternoon (though my version with the implementation of my
flattener also exhibits this behavoir). Notice the large variation
in total allocation between the two instances of the checksum benchmark.
If you run the same executables with @mlton gc-summary --  the numbers do
not match up.

-Luke

skavena 260 $ ./mlton -drop-pass flatten -drop-pass localFlatten1
-drop-pass localFlatten2 -drop-pass localFlatten3 -profile alloc
checksum.batch.sml
skavena 261 $ ./checksum.batch
skavena 262 $ ./mlprof checksum.batch mlmon.out
45,010,009,860 bytes allocated (1,252 bytes by GC)
    function       cur
----------------- ------
fold.loop         100.0%
Main.doit           0.0%
<main>              0.0%
<gc>                0.0%
MLtonProcess.exit   0.0%
PosixIO.isReg       0.0%



skavena 263 $ ./mlton -profile alloc checksum.batch.sml
skavena 264 $ ./checksum.batch
skavena 265 $ ./mlprof checksum.batch mlmon.out
10,008,856 bytes allocated (1,252 bytes by GC)
    function       cur
----------------- -----
Main.doit         99.9%
<main>             0.1%
<gc>               0.0%
PosixIO.isReg      0.0%
MLtonProcess.exit  0.0%