# [MLton] space safety for structures

**Daniel C. Wang
**
danwang@CS.Princeton.EDU

*Fri, 02 Jul 2004 22:27:32 -0400*

Hmm... one should ask a real guru, but I supsect if you use CM rather than
the REPL you may get a different result. I'd swear the SML/NJ folk know
about this space leak, and I thought they had done something to solve this
... but perhaps I'm wrong..
Stephen Weeks wrote:
>* To test my model, I fed the following program to SML/NJ.
*>*
*>* ------------------------------------------------------------
*>* structure A =
*>* struct
*>* val n = 100
*>* val n = Array.maxLen
*>* val a = Array.array (n, 13)
*>* val x = 0
*>* end
*>* ; (* The semicolon is important so that F and A are compiled separately. *)
*>* functor F () =
*>* struct
*>* val _ = print (concat ["F ", Int.toString A.x, "\n"])
*>* end
*>* structure A = struct end
*>* val _ = SMLofNJ.exportML "z"
*>* ------------------------------------------------------------
*>*
*>* As it stands, this produces a 77,696,284 byte heap. On the other
*>* hand, if I swap the definitions of A.n, so that that A.a is only 100
*>* elements, then the heap is 10,595,540 bytes. The difference between
*>* those sizes is is 67,100,744, which is quite close to 4 *
*>* Array.maxLen. So, SML/NJ is clearly keeping A.a alive, even though it
*>* is dead. I conjecture this is because SML/NJ represents F as a
*>* closure that refers to the representation of A as a tuple, not as a
*>* closure that refers to the individual elements of A that F uses.
*>*
*