[MLton] share weirdness

[Henry Cejtin]

Ok,  the fix to gc.c definitely seems to have solved the sefault problem, but
there is still one unexplained weirdness.  Pretty much the  last  thing  that
the program does after constructing this large complicated object is to print
out its size, then to call MLton.shareAll and then  to  print  out  the  size
again.

When  I run this on my machine at home, an Athlon with a 2.6 kernel and 2 gig
of RAM, the two sizes are:

        1,027,105,340 before
          980,913,040 after

Running exactly the same compiled executable on exactly  the  same  input  at
work,  which  is 935 MHz SMP machine (2 CPUs), a 2.4 kernel and 2 gig of RAM,
the two sizes are:

        1,027,105,340 before
          981,014,212 after

I.e., with the 2.4 kernel, slightly less sharing is detected.  Any  idea  how
this  could  be?  Could it be that the sharing code is looking at some unused
bytes in an object and concluding that two objects  aren't  identical.   Even
this  `explanation'  would  require  some  statement as to how the background
bytes got to be different.

Definitely rather mysterious to me.