[MLton] callcc and space use

[Matthew Fluet]

On Wed, 23 Jan 2008, Matthew Fluet wrote:
> 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.

Another interesting observation is that the 'total allocated' statistic is 
the same (approx 27M).  That would seem to suggest a leak of some form -- 
the programs are allocating the same data, just one of them keeps some of 
that data live longer than the other.