From mboxrd@z Thu Jan 1 00:00:00 1970 X-Sympa-To: caml-list@inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q03EuMXS026692 for ; Tue, 3 Jan 2012 15:56:22 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUGALMWA0+K57AEmWdsb2JhbABDDoF3qCCCOyIBAQEBAQgLCwcUJYFyAQEFJwsBBUABEAshFgQLCQMCAQIBRQYNAQcCvQ6MDwSaUYNNiGE4 X-IronPort-AV: E=Sophos;i="4.71,450,1320620400"; d="scan'208";a="137677632" Received: from ariane.ens-cachan.fr ([138.231.176.4]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 03 Jan 2012 15:56:15 +0100 Received: from localhost (localhost [127.0.0.1]) by ariane.ens-cachan.fr (Postfix) with ESMTP id F0B0ABDA70; Tue, 3 Jan 2012 15:56:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at ens-cachan.fr Received: from ariane.ens-cachan.fr ([127.0.0.1]) by localhost (ariane.ens-cachan.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1A8OkgV20DLZ; Tue, 3 Jan 2012 15:56:15 +0100 (CET) Received: from olive.lsv.ens-cachan.fr (olive.lsv.ens-cachan.fr [138.231.81.248]) by ariane.ens-cachan.fr (Postfix) with ESMTP id D63B3BDA62; Tue, 3 Jan 2012 15:56:15 +0100 (CET) Received: from [138.231.81.43] (unknown [138.231.81.43]) by olive.lsv.ens-cachan.fr (Postfix) with ESMTP id CE7E64C019A; Tue, 3 Jan 2012 15:56:15 +0100 (CET) Message-ID: <4F031739.5020307@lri.fr> Date: Tue, 03 Jan 2012 15:56:57 +0100 From: Romain Bardou User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: syshen CC: caml-list@inria.fr References: <120102000101a0b992e1022cf562e46ade0873e35270@nudt.edu.cn> In-Reply-To: <120102000101a0b992e1022cf562e46ade0873e35270@nudt.edu.cn> Content-Type: text/plain; charset=x-gbk; format=flowed Content-Transfer-Encoding: 8bit X-Validation-by: bardou@lri.fr Subject: Re: [Caml-list] Will the data allocated by caml_alloc be automatically freed by g arbage collector? Le 01/01/2012 17:01, syshen a ¨¦crit : > > Dear All: > > I am writing a program that include a main loop written in Ocaml and a > sub-module written in C. The main loop called the sub-module a lot, and > a huge array is returned from each call. > > So I use the standard C-Caml interface to return these huge data as > shown below: > > extern "C" value minisat_save_proof(value unit) { > CAMLparam0(); > CAMLlocal1( ml_data ); > vec& vi=(solver->proof)->save("minisat_save_proof"); > int sz=vi.size(); > ml_data = caml_alloc (sz,0); > for (int i=0;i Store_field( ml_data, i, Val_int((int)(vi[i])) ); > } > CAMLreturn( ml_data ); > } > > In the main ocaml program loop, there is a call to a ocaml method A, > which again call this C method minisat_save_proof. > > When ocaml method A got these data returned from minisat_save_proof, it > call another method B to clear all data structure in the sub-module > written in C, and then exit to the main loop and call Gc.compress to > collect all garbage. > So in this case I think the memory usage of my program should be the > same like before calling minisat_save_proof , because the returned data > should be collected by the garbage collector when exiting the method A > to the main loop. > > But from the unix "top" command, I find that these huge return data > seems to remain in memory and consume all my memory step by step. > > So I want to know if there is any method to free these data? Hello, As far as I know, yes, caml_alloc() allocates its data in the OCaml heap and your big value will thus be garbage collected. Maybe you could check that your value is indeed garbage collected by using: Gc.finalise (fun _ -> print_endline "I am being garbage collected") v where v is the value returned by minisat_save_proof. If the value is not garbage collected, then maybe you forgot that you put the value in some table or something. Cheers,