caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Philippe Wang <philippe.wang.lists@gmail.com>
To: Jon Harrop <jon@ffconsultancy.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] OC4MC : OCaml for Multicore architectures
Date: Thu, 24 Sep 2009 16:51:45 +0200	[thread overview]
Message-ID: <4d1b2df20909240751q3f8b67dbl285788ab6487dcf8@mail.gmail.com> (raw)
In-Reply-To: <200909241411.58823.jon@ffconsultancy.com>

On Thu, Sep 24, 2009 at 3:11 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> Are values such as float arrays copied in their entirety or are they allocated
> outside the shared heap and only a pointer to them is copied?

They should be in a heap (page or shared). We don't allocate many
things outside the heaps.

> Is the copy operation parallelized?

Nope. When the world is stopped for the collection, everything is done
sequentially until the world is resumed.
I don't think it's relevant to parallelize the copy operation (hell to
implement&debug, then I don't think that performance would be very
interesting because we would probably need a write mutex on the
destination heap)

> Is there a write barrier but no read barrier? If so, what exactly does the
> write barrier do?

There is a lock when a thread is created because we need to update the
list of existing threads and we have to give it a page.
Then, each time a thread wants memory, it checks if the world needs to
be stopped. If the world needs to be stopped, it means that there is a
necessary collection waiting for the world to be stopped.
There is lock if a thread needs to allocate memory in the shared heap
so that two threads don't end up using the same space for different
things.
If two threads want to write in the same block, it's up to the
programmer to prevent (or allow) such a thing with a mutex (or
whatever other mechanism).

>> Special operations :
>> - if there is a blocking operation (e.g. mutex lock or I/O operation),
>> the mechanism is roughly the same as original INRIA OCaml's : it tells
>> the GC that there is no need to stop it when stopping the world.
>
> Can users mark external calls in their bindings as blocking so the GC will
> treat them appropriately?

Yes, it's the same as INRIA OCaml : enter_blocking_operation /
leave_blocking_operation functions.
It's mandatory that in the section between entrance and exit, the
thread is not accessing anything allocated in a Caml heap.
If there is need to write some value returned by the blocking
operation, it should be written in a C side value (on C stack or with
C malloc) and put back to Caml heap after exit (and then C free if C
malloced).


-- 
Philippe Wang
   mail@philippewang.info


  reply	other threads:[~2009-09-24 14:55 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-22 21:30 Philippe Wang
2009-09-23 10:53 ` [Caml-list] " Goswin von Brederlow
2009-09-23 12:21   ` Jon Harrop
2009-09-23 13:00     ` Jon Harrop
2009-09-23 14:26       ` Philippe Wang
2009-09-24  0:21   ` Jon Harrop
2009-09-23 23:15     ` Philippe Wang
2009-09-24  0:05       ` Jon Harrop
2009-09-24  0:01         ` Philippe Wang
2009-09-24  1:47           ` Jon Harrop
2009-09-24  9:49             ` Richard Jones
2009-09-24 10:00               ` rixed
2009-09-24 10:40               ` Florian Hars
2009-09-24 11:45               ` Jon Harrop
2009-09-24 10:00             ` kcheung
2009-09-24 11:52               ` Jon Harrop
2009-09-24 11:55                 ` Rakotomandimby Mihamina
2009-09-24 12:11                 ` rixed
2009-09-24 15:58                   ` Jon Harrop
2009-09-24 12:39                 ` Stefano Zacchiroli
2009-09-24 13:09                   ` Jon Harrop
2009-09-24 16:49                     ` Richard Jones
2009-09-24 16:56                       ` Philippe Wang
2009-09-24 17:36                         ` Richard Jones
2009-09-24 19:39                         ` rixed
2009-09-24 21:09                       ` Jon Harrop
2009-09-24 21:26                         ` rixed
2009-09-25  4:07                         ` Jacques Garrigue
2009-09-25  7:32                           ` Hugo Ferreira
2009-09-25 10:17                             ` Jon Harrop
2009-09-25 13:04                               ` kcheung
2009-09-25 21:39                             ` Gerd Stolpmann
2009-09-25  9:33                           ` Philippe Wang
2009-09-25 21:39                           ` Jon Harrop
2009-09-26 16:55                             ` Jon Harrop
2009-09-25  8:08                         ` Stéphane Glondu
2009-09-25 15:05                     ` Xavier Leroy
2009-09-25 23:26                       ` Benjamin Canou
2009-09-26  0:45                         ` kcheung
2009-09-26  1:53                           ` Jon Harrop
2009-09-26 13:51                             ` kcheung
2009-09-26 14:46                               ` Jon Harrop
2009-10-10  4:01                         ` Jon Harrop
2009-09-24 13:40                   ` Rakotomandimby Mihamina
2009-09-24 14:22                     ` Philippe Wang
2009-09-24 14:49                     ` Stefano Zacchiroli
2009-09-24 13:55                   ` Mike Lin
2009-09-24 14:52                     ` Stefano Zacchiroli
2009-09-24 15:36                 ` Philippe Wang
2009-09-24 15:50                   ` Jon Harrop
2009-09-24 12:14             ` Philippe Wang
2009-09-24 13:11               ` Jon Harrop
2009-09-24 14:51                 ` Philippe Wang [this message]
2009-09-24 14:57       ` Philippe Wang
2009-09-24 14:11 ` Dario Teixeira
2009-09-24 14:38   ` Philippe Wang
2009-09-24 15:20     ` Dario Teixeira
2009-09-24 23:28     ` Jon Harrop
2009-09-24 23:25       ` Philippe Wang
2009-09-25 14:11       ` Philippe Wang
2009-11-08 18:12       ` Jon Harrop
2009-09-24 18:24 ` David Teller
     [not found] <20090924154716.BCD0ABC5A@yquem.inria.fr>
2009-09-24 16:02 ` Pascal Cuoq
2009-09-24 16:30   ` Philippe Wang

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=4d1b2df20909240751q3f8b67dbl285788ab6487dcf8@mail.gmail.com \
    --to=philippe.wang.lists@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=jon@ffconsultancy.com \
    /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).