English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Re: [Caml-list] Re: ocaml sefault in bytecode: unanswered questions
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-08-10 (04:14)
From: ivan chollet <ivan.chollet@f...>
Subject: RE: [Caml-list] Re: ocaml sefault in bytecode: unanswered questions
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
> 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
> be called on a regular basis while in function myfun. :p>
> Then List.iter is tail-recursive, so it doesn't push its successive
> on the stack. So the successively created myref become unreachable while
> 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
> 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.