RE: [Caml-list] memory leak in toplevel? or, how to implement sizeof

[David Allsopp <dra-news@metastack.com>]

Jim Pryor wrote:
> Starting up the toplevel fresh, with no .ocamlinit file, I see this:
> 
>     $ /usr/bin/ocaml
>             Objective Caml version 3.12.0
> 
>     # Gc.(compact();counters());;
>     - : float * float * float = (79217., 32932., 82668.)
>     # Gc.(compact();counters());;
>     - : float * float * float = (93530., 32932., 85816.)
>     # Gc.(compact();counters());;
>     - : float * float * float = (107843., 32932., 88964.)
> 
> Why do both the minor_words and major_words keep climbing? Do these
> indicate the number of words _ever_ allocated,

The docs clearly state that is "ever" allocated - see type Gc.stat in the reference manual.

> and so the overhead of
> doing the garbage collection and compacting has pushed them up? Or do they
> indicate the number of words _now_ allocated, so the fact that they
> continue to climb indicates something is leaking memory?

There are all kinds of things going on when you do this - even the result of Gc.counters causes an allocation (it has to create a tuple to return the numbers). The toploop uses the Parsing module to parse each expression and that will result in some allocations. Printf probably allocates as well (which is responsible for the displaying the output in the toploop). If you re-order the variables to do the three statements in a row and then print all nine results at the end then you'll see a rise which looks pretty consistent with just the allocation of your nine variables and the tuples coming from Gc.counters.


David