From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id EDCB4BBAF for ; Sun, 9 Aug 2009 18:14:07 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQCAKaSfkrZSMDje2dsb2JhbACBUph5AQELCwoFEwWwfgKEFgWBTFs X-IronPort-AV: E=Sophos;i="4.43,349,1246831200"; d="scan'208";a="44497162" Received: from fmmailgate02.web.de ([217.72.192.227]) by mail4-smtp-sop.national.inria.fr with ESMTP; 09 Aug 2009 18:14:07 +0200 Received: from smtp07.web.de (fmsmtp07.dlan.cinetic.de [172.20.5.215]) by fmmailgate02.web.de (Postfix) with ESMTP id 041A5111F8462; Sun, 9 Aug 2009 18:14:07 +0200 (CEST) Received: from [95.208.117.111] (helo=frosties.localdomain) by smtp07.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #314) id 1MaB26-0000Xc-00; Sun, 09 Aug 2009 18:14:06 +0200 Received: from mrvn by frosties.localdomain with local (Exim 4.69) (envelope-from ) id 1MaB26-0004mW-Ff; Sun, 09 Aug 2009 18:14:06 +0200 From: Goswin von Brederlow To: "ivan chollet" Cc: "'David Allsopp'" , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: ocaml sefault in bytecode: unanswered questions References: <000301ca184b$032b8cc0$0982a640$@chollet@free.fr> <000701ca184d$29507e90$7bf17bb0$@metastack.com> <001001ca18c7$37b22220$a7166660$@chollet@free.fr> Date: Sun, 09 Aug 2009 18:14:06 +0200 In-Reply-To: <001001ca18c7$37b22220$a7166660$@chollet@free.fr> (ivan chollet's message of "Sun, 9 Aug 2009 09:58:43 +0200") Message-ID: <87zla955ip.fsf@frosties.localdomain> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.22 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX1/qSyqatEyIsgx/NFbG4Deux9PsmVNvPrITX5x4 VQPxt6dKorz2hDBFDxn5/xw/s9dMkH8x+J+vNn7qlQm9h2/z9X lcHEL3ZWU= X-Spam: no; 0.00; ocaml:01 bytecode:01 real-world:01 myfun:01 iter:01 myfun:01 iteration:01 allocations:01 iter:01 iterating:01 iteration:01 ocamlrun:01 mfg:98 garbage:01 stack:01 "ivan chollet" writes: > :v="urn:schemas-microsoft-com:vml" > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:w="urn:schemas-microsoft-com:office:word" > xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" > xmlns="http://www.w3.org/TR/REC-html40"> > > Definitely.:p> > > Actually I had my real-world case in mind, so let me explain further with the > following snippet::p> > > :p>  > > let myfun = doSomeWork (); myref := List.filter somefilterfunction !myref > in:p> > > List.iter myfun !myref:p> > > :p>  > > In this case, a new linked list is created in each iteration of the > List.filter. (that is, a new list allocation):p> > > Then, if doSomeWork () does a lot of work and lots of allocations, the GC will > be called on a regular basis while in function myfun. :p> > > Then List.iter is tail-recursive, so it doesn't push its successive arguments > on the stack. So the successively created myref become unreachable while still > iterating on them.:p> > > So my question is, how does the GC know whether all these myref created > throughout the iteration are collectable or not? I'm curious about how these > myref are tagged/untagged by the garbage collector. Maybe pointing me the > relevant portions of the ocamlrun source code would be nice.:p> The current value of each binding is on the stack and the GC knows about that. In the tail-recursion the value on the stack is successively replaced by newer ones while the old ones are forgotten. The GC then marks everything known (reachable) as still being needed and everything it can't reach recursively from the known values your code can't reach either and the GC can free it. But that isn't even what happens in your case. Your myref is not on the stack and you do not create a new myref on every iteration. You only change its value. The GC knows about the myref and it will be one of the known (reachable) things the GC starts from. MfG Goswin