From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 5ED687EC6E for ; Mon, 23 Jun 2014 10:58:27 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of francois.bobot@cea.fr) identity=pra; client-ip=132.167.192.142; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="francois.bobot@cea.fr"; x-sender="francois.bobot@cea.fr"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of francois.bobot@cea.fr designates 132.167.192.142 as permitted sender) identity=mailfrom; client-ip=132.167.192.142; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="francois.bobot@cea.fr"; x-sender="francois.bobot@cea.fr"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@cirse-out.extra.cea.fr) identity=helo; client-ip=132.167.192.142; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="francois.bobot@cea.fr"; x-sender="postmaster@cirse-out.extra.cea.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4BAKTrp1OEp8COnGdsb2JhbABZg1+DR8ELAYEKFg8BAQEBAQgLCQkUKIQDAQEFIw8BRRELGAICBRYLAgIJAwIBAgFFEwgCF4gnDahPnVgTBIEqjVkWgmGBTASOBpNDgQKPKA X-IPAS-Result: As4BAKTrp1OEp8COnGdsb2JhbABZg1+DR8ELAYEKFg8BAQEBAQgLCQkUKIQDAQEFIw8BRRELGAICBRYLAgIJAwIBAgFFEwgCF4gnDahPnVgTBIEqjVkWgmGBTASOBpNDgQKPKA X-IronPort-AV: E=Sophos;i="5.01,528,1400018400"; d="scan'208";a="68423609" Received: from cirse-out.extra.cea.fr ([132.167.192.142]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2014 10:58:26 +0200 Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5N8wQGP005337 for ; Mon, 23 Jun 2014 10:58:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5EC6A202D57 for ; Mon, 23 Jun 2014 11:00:20 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 572F4202B0C for ; Mon, 23 Jun 2014 11:00:20 +0200 (CEST) Received: from [10.8.32.80] (is222783.intra.cea.fr [10.8.32.80]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s5N8wQiV008397 for ; Mon, 23 Jun 2014 10:58:26 +0200 Message-ID: <53A7EE06.5060209@cea.fr> Date: Mon, 23 Jun 2014 11:06:14 +0200 From: =?UTF-8?B?RnJhbsOnb2lzIEJvYm90?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <53A70E28.2030804@gmail.com> In-Reply-To: <53A70E28.2030804@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] Memory leaks generated by Scanf.fscanf? On 22/06/2014 19:11, Benoît Vaugon wrote: > I attach a samll patch based on weak-pointers that seems to solve > the problem.The Jean-Vincent example now prints something like: Wow! That's a funny solution, but I'm just afraid that it rely on a bad behavior of the GC that the first three commits of !22 (https://github.com/ocaml/ocaml/pull/22) correct. In english terms, what Benoît does: - put the key in a weak-set to be able to test if it disappeared - create a pair that store the key and the associated value - put this pair in a weak set, where it will be reclaimed at the next GC because it is reachable only through a weak pointer. - add a finalizer on the pair that add again the pair in the weak set at each GC - stop to add it when the key is not present anymore. The correction of this algorithm rely on the following (good, IMHO) behavior: - A value which have an attached finalizer is marked alive, so an ocaml function can run with this function and one can make it reachable again. and the following bad behavior: - The weak pointers are cleaned before the marking of finalized pointer. If the cleaning is done later, the pair is marked, then the key is marked, the key is not removed from the weak-set, thus the key never disappear. The fact that "The weak pointers are cleaned before the marking of finalized pointer" is bad mainly because you don't have anymore the property that if a value disappear from a weak set then it have been reclaimed and can't be used anymore. Use of (==) and tag in hashconsed values are based on this property. Moreover the fact that the cleaning of weak pointer is done during the marking phase can also lead to a value disappearing from a weak set but not from another. In conclusion the ephemerons are the real solution for the 4.03 release. For the 4.02 I'm not sure the added complexity and memory/cpu cost is worse it. Moreover I don't understand why Scanf.from_channel must be memoized by the library. Can't we say that the user of the library shouldn't call it twice with the same value? The example of jean-vincent loddo will work with such API, no? We can also add a new not memoized function. -- François