caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "ivan chollet" <ivan.chollet@free.fr>
To: <goswin-v-b@web.de>
Cc: <caml-list@yquem.inria.fr>
Subject: RE: [Caml-list] Re: ocaml sefault in bytecode: unanswered questions
Date: Mon, 10 Aug 2009 06:14:27 +0200	[thread overview]
Message-ID: <000601ca1971$0dee7290$29cb57b0$@chollet@free.fr> (raw)
In-Reply-To: <87zla955ip.fsf@frosties.localdomain>

Hi Goswin, 

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] 
Sent: dimanche 9 août 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" <ivan.chollet@free.fr> 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


      reply	other threads:[~2009-08-10  4:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-08 17:09 ivan chollet
2009-08-08 17:24 ` [Caml-list] " David Allsopp
2009-08-09  7:58   ` ivan chollet
2009-08-09 10:16     ` Michel Mauny
     [not found]     ` <001501ca18cc$d59a61a0$80cf24e0$@metastack.com>
2009-08-09 12:06       ` ivan chollet
2009-08-09 13:20         ` David Allsopp
2009-08-09 13:55         ` Alain Frisch
2009-08-09 14:13           ` ivan chollet
2009-08-09 18:56           ` Elnatan Reisner
2009-08-09 19:09             ` Alain Frisch
2009-08-10 13:22               ` Elnatan Reisner
2009-08-10 13:36                 ` Martin Jambon
2009-08-10 14:26                   ` Elnatan Reisner
2009-08-09 16:14     ` Goswin von Brederlow
2009-08-10  4:14       ` ivan chollet [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000601ca1971$0dee7290$29cb57b0$@chollet@free.fr' \
    --to=ivan.chollet@free.fr \
    --cc=caml-list@yquem.inria.fr \
    --cc=goswin-v-b@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).