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 p1AE4ngK024668 for ; Thu, 10 Feb 2011 15:04:49 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUBAKR/U01KfVI0k2dsb2JhbACXI44+CBUBAQEBCQkKCREEIKACigyCGYRlL4haAQEDBYVXBIdDhDaIODo X-IronPort-AV: E=Sophos;i="4.60,451,1291590000"; d="scan'208";a="75699370" Received: from mail-ww0-f52.google.com ([74.125.82.52]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 10 Feb 2011 15:04:41 +0100 Received: by wwd20 with SMTP id 20so1342851wwd.9 for ; Thu, 10 Feb 2011 06:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=YGdXf6r813K7hHAjnDtDT+oR56NppvB+HIuzYtHuehc=; b=LT4C5jQGm7TM03tvHZAkAE3s8Zl2Jm5cH4kG/R5ZZyHn/LlgXIHjeDqJKxpQsfa+1o 3y0yR+LZZvQDwPzv9EXrMQcdBd0mWY7bAhJ7wUa7DSovIcHTmkqak4RUXw/BXVeuqfpO YqVc5EasehQS7W+pOENrnoEHBMYmX8DmLmDO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=M9GI94HdcZGlM/mBRpMXb4h2iUIRIM87H1C9NzAw3NcFyI5CccjwnWCrmaayUoRrUG lKkR9dM9NUKgMeAwSunCp97LI08gYKL+0boY04Fcif2rujXaoigSyTqR0TavCUdH645d yp4Kn8uKFdxEPB4WUaZ+iRLBHVKBx3sA2Vt68= MIME-Version: 1.0 Received: by 10.227.69.198 with SMTP id a6mr587320wbj.127.1297346680595; Thu, 10 Feb 2011 06:04:40 -0800 (PST) Received: by 10.227.136.202 with HTTP; Thu, 10 Feb 2011 06:04:40 -0800 (PST) Reply-To: david.baelde@ens-lyon.org In-Reply-To: References: Date: Thu, 10 Feb 2011 15:04:40 +0100 Message-ID: From: David Baelde To: Raoul Duke Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Structural avoidance of memory leaks? 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