caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Sylvain Le Gall <sylvain@le-gall.net>
To: caml-list@inria.fr
Subject: Re: ocaml sefault in bytecode: unanswered questions
Date: Sat, 8 Aug 2009 21:14:45 +0000 (UTC)	[thread overview]
Message-ID: <slrnh7rqm5.rtu.sylvain@gallu.homelinux.org> (raw)
In-Reply-To: <23185.6251172305$1249751407@news.gmane.org>

On 08-08-2009, ivan chollet <ivan.chollet@free.fr> wrote:
>
> Yes it was a freebsd 6.4 with ocaml 3.10.2
>

OCaml version is quite old, but should be ok.

> I'll run the program on linux later and see how it goes.
>
>  
>
> Thanks for your advices regarding debugging. I pretty much tried all of
> these though. the thing is my error is not an ocaml error at runtime but an
> error of the ocaml runtime. And to analyze a core dump of ocamlrun, I just
> thought my best bet was gdb. Whatever.
>
>  
>
> OK I'll try to provide you with a minimal ocaml code that produce an
> ocamlrun error. Might take a little while as I'm not free.
>
> In the meantime, I've got a newbie question regarding ocaml garbage
> collector and the same List.iter stuff:
>
> Say you do a "List.iter myfun !myref", where !myref is a list (hehe.), and
> where myfun is a function that does reallocations of myref (that is
> affectations like myref := [some new or old objects]). The pointers myref
> that are generated through this process are destroyed each time a new
> reallocation of myref is done. Of course the underlying linked lists that
> are not referenced anymore shouldn't be collected by the GC before the end
> of the main "List.iter", otherwise it's iterating through a linked list that
> has been garbage collected.
>
> My question is: does the GC know that it cannot collect the unreferenced
> myref pointers before the end of the List.iter? 
>


Why "the underlying linked lists that not referenced anymore shouldn't
be collected by the GC before the end the main "List.iter"" ?

OCaml list are single-linked list, whenever you cannot access the head
of the list everything until the current element can be GCed.

Here is the implementation of List.iter

let rec iter f = function
    [] -> ()
  | a::l -> f a; iter f l

As soon as you apply "myfun" to "a", the reference to a is not used so
it can be collected by the GC if there is no more reference to it.

I think the GC CAN collect the unreferenced myref pointers before the
end of the List.iter...

Regards
Sylvain Le Gall


       reply	other threads:[~2009-08-08 21:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <23185.6251172305$1249751407@news.gmane.org>
2009-08-08 21:14 ` Sylvain Le Gall [this message]
2009-08-08 17:09 ivan chollet
     [not found] <16043.1656208404$1249662628@news.gmane.org>
2009-08-08  9:37 ` Sylvain Le Gall
  -- strict thread matches above, loose matches on Subject: below --
2009-08-07 16:29 ivan chollet

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=slrnh7rqm5.rtu.sylvain@gallu.homelinux.org \
    --to=sylvain@le-gall.net \
    --cc=caml-list@inria.fr \
    /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).