From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p198lsI1013821 for ; Wed, 9 Feb 2011 09:47:54 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4BACPjUU3RVaE2imdsb2JhbAClPAgVAQEBCgkMBw8GIKJOjCOESokIAQEDBYVWBItuiDI6gQ6BcQ X-IronPort-AV: E=Sophos;i="4.60,446,1291590000"; d="scan'208";a="75607771" Received: from mail-fx0-f54.google.com ([209.85.161.54]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-MD5; 09 Feb 2011 09:47:49 +0100 Received: by fxm16 with SMTP id 16so7837545fxm.27 for ; Wed, 09 Feb 2011 00:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=PUcgwaJkNlau3w3dmG82Qyr4GQ4XDmFa3WMKWzq7T/k=; b=gMmg67aeg/VtAGP50zmhicAiEhJW/B+rpG/nKoVIlCQb5B3BeabqQpYO5Vi3X2qFjN DdRNTsKMjxNT6HttuMQUz08Cuofg2hsLbuyAhW6kgSPadwbrDUEp8Ca31QvrrOhpFYch 30qvfQZzZl4e8SRIVdSnOYFa2S5PdFeIwDhzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; b=HjlmpJyQg4ux8neFw71967fyQkuMLxkaow+Nxosq++Zz+MSkXf1yHs4siny+ViDXtT Eo6AqF380C6qbqzCnpFs3CItbv+b05UcTJomju/IO6W7XYB6aqssYGAta7H0+fmRBQXP g0ChkGmxTRtA6qXSu/HOJ0SDWoFaVxcpNBZuk= Received: by 10.223.74.200 with SMTP id v8mr2529334faj.144.1297241268383; Wed, 09 Feb 2011 00:47:48 -0800 (PST) MIME-Version: 1.0 Sender: david.mentre@gmail.com Received: by 10.223.110.199 with HTTP; Wed, 9 Feb 2011 00:47:18 -0800 (PST) From: David MENTRE Date: Wed, 9 Feb 2011 09:47:18 +0100 X-Google-Sender-Auth: 9OuYuLnzL5-VafbObizoUBtlmUc Message-ID: To: Jacques Garrigue Cc: orbitz@ezabel.com, caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Subject: [Caml-list] Structural avoidance of memory leaks? Hello Mr. Garrigue, 2011/2/9 Jacques Garrigue : > * 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