[MLton] callcc and space use

[Matthew Fluet]

On Wed, 23 Jan 2008, Daniel Spoonhower wrote:
> Vesa Karvonen wrote:
>>  On Jan 23, 2008 3:03 PM, Daniel Spoonhower <spoons at cs.cmu.edu> wrote:
>>  [...]
>> >  I attached a small(-ish) example.  It copies and reverses a list of
>> >  reals.  Toward the end of execution there are more than 4000 live cons
>> >  cells in the heap, though the length of the input list is only 75.
>>
>>  BTW, how did you get the numbers?
>
> I just added a few lines to the collector to count how many objects of each 
> object type were found.  There was only one object type that looked like a 
> list of reals.

I could observe the leak simply by putting a call to "MLton.GC.collect" in 
the "loop" function, running the program with "@MLton gc-summary", and 
observing the 'max live' statistic.  (The live bytes statistic is only 
accurate after a major garbage collection, to forcing the program to 
frequently garbage collect is a way of ensuring the statistic is accurate 
and doesn't miss a spike in live bytes between normal (heap limit induced) 
garbage collections.)   Going to an input size of 750 made the problem 
quite visible: simple1 had max live > 4M, while simple2 had max live 
approx 130K.

It is certainly a real effect, and AFAICT the two programs are equivalent. 
But, I've no immediate explaination.

>>  Glancing at the programs, I quickly spotted one place where you might
>>  have a "leak" (I don't yet understand the whole program), and this
>>  differs between the two versions of the program you sent....
>
> Thanks for pointing that out.  Unfortunately, it doesn't seem to make much 
> difference.  I.e. the non-leaky one stays non-leaky even if I make it 
> non-tail recursive, and the leaky one stays leaky even if I make it tail 
> recursive.  That function ("loop") doesn't have much state, so even if it was 
> leaking frames on the stack, it should only be a linear overhead.

I believe that MLton will recognize that the loop function never returns 
normally, and so the