[MLton] share weirdness
Henry Cejtin
henry.cejtin@sbcglobal.net
Thu, 20 Apr 2006 16:22:24 -0500
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.