Re: [Caml-list] Questions on replacing finalizers and memory footprints

[Hendrik Tews <tews@cs.ru.nl>]

Jean-Christophe Filliâtre <Jean-Christophe.Filliatre@lri.fr>
writes:

   > Jean-Christophe Filliâtre's "size" library does exactly this:
   > 
   >        http://www.lri.fr/~filliatr/software.en.html

   Indeed. However, note that it uses internally a hash table to store
   blocks already considered (in order to correctly account for sharing),
   and thus it is potentially incorrect if the GC moves some blocks during
   the count, for instance during a resizing of the hash table (which
   triggers the GC). I don't know how to avoid this issue; any help is welcome.

Use the normal hash function (ie. the hash depends on the block
and not on its address) and use the blocks themselves as keys!
Then the GC will not change the hash and will update the keys in
the hash table. Of course all in a hash table with physical
equality. I use this solution in memcheck
(http://www.cs.ru.nl/~tews/memcheck/).

The problem is that your runtime will be quadratic in the number
of blocks that are equal (=) but different (not ==). For my
applications of memcheck this is problematic, because the data
contains lots of (ref None) blocks, which cannot be identified
for obvious reasons.

The (apparently abondoned) ocaml-ty branch
(http://www.pps.jussieu.fr/~henry/marshal/) uses a list instead
of a hash table and is therefore quadratic in _all_ blocks. The
performence is only sufficient for toy applications (4 hours for
checking 4MB).

For applications like size or memcheck it would be nice if the GC
could notify the program when it moves blocks.

Bye,

Hendrik

(Better answering late than never...)