[MLton] Tagged ref and array pointers

[Wesley W. Terpstra]

I was debugging what I thought was a space leak when I discovered that
MLton doesn't seem to use the lower 2 bits of a pointer to ref/array
objects.

For example, the program:
datatype foo =
   COOL_ALLOC of int ref
 | USABLE_ALLOC of int ref

val z = ref 7
val y = ref 9

val x = Array.tabulate (10, fn _ => COOL_ALLOC y)
val () = Array.update (x, 3, USABLE_ALLOC y)
val () = Array.update (x, 4, USABLE_ALLOC z)
val () = Array.update (x, 5, COOL_ALLOC y)
val () = Array.update (x, 6, COOL_ALLOC z)
val () = print (Int.toString (MLton.size x) ^ "\n")
val () = MLton.dot ("meh.dot", "meh", SOME x)

val out = fn
   COOL_ALLOC x => print (Int.toString (!x) ^ "c")
 | USABLE_ALLOC x => print (Int.toString (!x) ^ "f")

val () = Array.app out x
val () = z := 5
val () = y := 6
val () = Array.app out x

val () = print "\n"

Produces the memory layout in the attached png file. You can see that
it represents the datatype using an intermediate heap object instead
of packing the flag into the low bits of the pointer to the ref cell.
I've seen the same behaviour with datatypes to a vector. MLton does
the right thing other times (tracking the variants of a datatype the
low bits of the pointer) for recursive datatypes and a few other
cases. Is there a good reason for it not performing this optimization
here?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meh.png
Type: image/png
Size: 15900 bytes
Desc: not available
Url : http://mlton.org/pipermail/mlton/attachments/20081112/926cad0e/meh-0001.png