[Caml-list] heap profiling

[Caml-list] heap profiling

[Fabrice Le Fessant]

Hi,

  I would like to know if anybody has implemented some kind of
memory/heap usage profiling for the current version (3.06) of Ocaml,
giving for example the amount of live data in the heap allocated by
each function or module ? or the amount of data retained by some root ?
  Anybody plans to implement such a tool ?

- Fabrice

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] heap profiling

[Jean-Christophe Filliatre]

Fabrice Le Fessant writes:
 > 
 >   I would like to know if anybody has implemented some kind of
 > memory/heap usage profiling for the current version (3.06) of Ocaml,
 > giving for example the amount of live data in the heap allocated by
 > each function or module ? or the amount of data retained by some root ?
 >   Anybody plans to implement such a tool ?

Regarding  the last  point  (the amount  of  data used  by some  ocaml
values(s)), I implemented a small  module Size for this purpose. It is
available at http://www.lri.fr/~filliatr/software.en.html

Hope this helps,
-- 
Jean-Christophe Filliâtre (http://www.lri.fr/~filliatr)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] heap profiling

[Fabrice Le Fessant]

>  Regarding  the last  point  (the amount  of  data used  by some  ocaml
>  values(s)), I implemented a small  module Size for this purpose. It is
>  available at http://www.lri.fr/~filliatr/software.en.html

The problem is that your Size module does not indicate which part of
the size retained by a root is maybe retained by other roots. By the
way, since garbage collections might occur during the execution of
your module, and objects moved in memory, some objects can be counted
twice by your function (only if they were in the minor heap or if
there is a compaction), leading to a small inaccuracy. You should
probably finish the major collection, and prevent compaction during
its execution.

- Fabrice

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] heap profiling

[Norman Ramsey]

 >   I would like to know if anybody has implemented some kind of
 > memory/heap usage profiling for the current version (3.06) of Ocaml,
 > giving for example the amount of live data in the heap allocated by
 > each function or module ? or the amount of data retained by some root ?

We would be thrilled to have such a tool, but we don't have the
resources to build one.  (I had a student try last summer, but the
project never really got anywhere.)

Our inability to understand the memory usage of our code is the single
greatest barrier to improving the performance of our Caml programs.


Norman

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] heap profiling

[Christian Lindig]

On Wed, Jul 09, 2003 at 12:10:52PM +0200, Fabrice Le Fessant wrote:
> I would like to know if anybody has implemented some kind of
> memory/heap usage profiling for the current version (3.06) of Ocaml,
> [..] Anybody plans to implement such a tool ?

No plans, but some thoughts. The time between the last use of a block
and its collection by the GC is called drag time. High drag times are
typical for leaked memory. To detect leaked blocks, a block is time
stamped when it is read or written, and the GC checks the drag time when
it finds the block dead. Blocks whose drag time exceeds a threshold are
logged. Time stamps and source code locations require additional room in
blocks. They main difficulty is to detect that a block is garbage such
that its drag time can be observed. 

I do know that custom blocks can have finalizers and therefore at least
they are individually identified as garbage. I don't know whether this
is true for other values in the OCaml GC. When the GC only scans the
live data it may be difficult to detect garbage block by block. Any GC
expert around to answer this question?

Does OCaml free all memory before exit? This would be useful to find the
memory that is otherwise never collected.

-- Christian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] expose GC roots as weak Obj.t pointers?

[Christian Lindig]

Would it be possible (in principle) to expose the GC roots as an array
of weak Obj.t pointers? This would allow to walk the heap from Caml
using Obj. 

    Gc.roots:   unit -> Obj.t Weak.t

-- Christian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] expose GC roots as weak Obj.t pointers?

[Damien Doligez]

On Thursday, July 10, 2003, at 10:02 AM, Christian Lindig wrote:

> Would it be possible (in principle) to expose the GC roots as an array
> of weak Obj.t pointers? This would allow to walk the heap from Caml
> using Obj.
>
>     Gc.roots:   unit -> Obj.t Weak.t

I think this should be possible.  Of course, you wouldn't want to 
examine
this data too often because it would prevent the GC from reclaiming
any memory.

-- Damien

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners