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=1.4 required=5.0 tests=AWL,MSGID_MULTIPLE_AT autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id DDA87BBAF for ; Mon, 10 Aug 2009 06:14:46 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0BACs7f0rLOwFri2dsb2JhbACZP4ENAQEBCgsKBxEGsTsChBYFgUxb X-IronPort-AV: E=Sophos;i="4.43,351,1246831200"; d="scan'208";a="30969578" Received: from outbound.icp-qv1-irony-out2.iinet.net.au ([203.59.1.107]) by mail2-smtp-roc.national.inria.fr with ESMTP; 10 Aug 2009 06:14:45 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsEAOk7f0p8qFdZ/2dsb2JhbACZP7J9AoQWBYFMWw X-IronPort-AV: E=Sophos;i="4.43,351,1246809600"; d="scan'208";a="548931239" Received: from unknown (HELO ivanz27oq2f1va) ([124.168.87.89]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP; 10 Aug 2009 12:14:41 +0800 From: "ivan chollet" To: Cc: References: <000301ca184b$032b8cc0$0982a640$@chollet@free.fr> <000701ca184d$29507e90$7bf17bb0$@metastack.com> <001001ca18c7$37b22220$a7166660$@chollet@free.fr> <87zla955ip.fsf@frosties.localdomain> In-Reply-To: <87zla955ip.fsf@frosties.localdomain> Subject: RE: [Caml-list] Re: ocaml sefault in bytecode: unanswered questions Date: Mon, 10 Aug 2009 06:14:27 +0200 Message-ID: <000601ca1971$0dee7290$29cb57b0$@chollet@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcoZDGuoF9CyzgXDT7W5Ta9cdrldPQAZCfrw Content-language: fr X-Spam: no; 0.00; ocaml:01 bytecode:01 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 2009:98 Hi Goswin,=20 Sorry there was a typo, I wanted to say new !myref (ie a new linked = list) are created each time you do the List.filter, so I thought the first = list on which you iterate wasn't referenced anymore but actually I misunderstood = how the GC scans the heap. I got it now! Thanks again -----Original Message----- From: goswin-v-b@web.de [mailto:goswin-v-b@web.de]=20 Sent: dimanche 9 ao=FBt 2009 18:14 To: ivan chollet Cc: 'David Allsopp'; caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: ocaml sefault in bytecode: unanswered = questions "ivan chollet" writes: > :v=3D"urn:schemas-microsoft-com:vml" > xmlns:o=3D"urn:schemas-microsoft-com:office:office" > xmlns:w=3D"urn:schemas-microsoft-com:office:word" > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" > xmlns=3D"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>=A0 > > let myfun =3D doSomeWork (); myref :=3D List.filter somefilterfunction = !myref > in:p> > > List.iter myfun !myref:p> > > :p>=A0 > > 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