"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