[Caml-list] Structural avoidance of memory leaks?

[Caml-list] Structural avoidance of memory leaks?

[David MENTRE]

Hello Mr. Garrigue,

2011/2/9 Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>:
> * Memory leaks: have to be careful that you are not referencing dead data, preventing the GC from freeing it.

I thought for a long time that having a GC would avoid any memory
leak. It appears that this is not the case. Java programmers are well
aware of the issue and apparently Haskell and OCaml programmers also.

Is there a documentation/paper/blog post/other somewhere that:
  * Explains where those memory leaks are coming from (i.e. more
precisely that "not referencing dead data")? Is there a taxonomy? Are
they tied to a specific language or are they generic to any language?
For example, in OCaml are memory leaks linked to imperative aspects or
can I have memory leaks using only purely functional aspects of the
language?

 * Tells me, as a practitioner, how to *structurally* avoid those
memory leaks? For example by avoiding some data structures or certain
kind of expressions.

Sincerely yours,
david

Re: [Caml-list] Structural avoidance of memory leaks?

[xclerc]

Le 9 févr. 2011 à 09:47, David MENTRE a écrit :

> Hello Mr. Garrigue,
> 
> 2011/2/9 Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>:
>> * Memory leaks: have to be careful that you are not referencing dead data, preventing the GC from freeing it.
> 
> I thought for a long time that having a GC would avoid any memory
> leak. It appears that this is not the case. Java programmers are well
> aware of the issue and apparently Haskell and OCaml programmers also.

The Java literature about this problem is in fact quite abundant.
One reason for this being that Java is widely used for server-side
applications that have a very long lifetime (think webserver, and
the like). This is why J2EE developer are particularly aware of the
problem. I would add that a related problem to some leaks in these
systems is security (e. g. keeping passwords or other sensitive information
in memory longer than needed).This is probably a problem some
OCaml developer face, maybe Ocsigen developers and/or users.

Finally, if you read some Java papers that refers to the "jconsole"
tool to discover such leaks, the closest OCaml equivalent I can
think of is ocamlviz:
	http://ocamlviz.forge.ocamlcore.org/


Hope this helps,

Xavier Clerc

Re: [Caml-list] Structural avoidance of memory leaks?

[Raoul Duke]

On Wed, Feb 9, 2011 at 12:47 AM, David MENTRE <dmentre@linux-france.org> wrote:
>  * Tells me, as a practitioner, how to *structurally* avoid those
> memory leaks? For example by avoiding some data structures or certain
> kind of expressions.

purity? i mean, avoid shared state, and of course shared mutable state.

Re: [Caml-list] Structural avoidance of memory leaks?

[David Baelde]

Hi list,

In my experience, that kind of problem happens with global references.
Of course, there's nothing to worry about with global immutable
things. We often have to use a global register of objects of some kind
(for unique identifiers, maintenance tasks, etc) and we forget that
this global store accumulates data over time and may become the only
reference to an object that should be dead. A simple solution is to
use weak tables when appropriate.

Memory leaks are less likely to be caused by a single function,
because they are generally not long lived, and the programmer of that
function would have in mind how much data it uses. It is possible to
have a function that runs forever and accumulates data (even a pure
function) but it'd generally be visible.

Cheers,
-- 
David