From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 02420BBAF for ; Thu, 24 Sep 2009 16:55:32 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4CAKsku0pKfVwai2dsb2JhbACDAo5HiHc/AQEBCgsKBxEFqm2BMY9tAQMCBIQXBQ X-IronPort-AV: E=Sophos;i="4.44,445,1249250400"; d="scan'208";a="33449377" Received: from qw-out-2122.google.com ([74.125.92.26]) by mail2-smtp-roc.national.inria.fr with ESMTP; 24 Sep 2009 16:55:31 +0200 Received: by qw-out-2122.google.com with SMTP id 8so544758qwh.15 for ; Thu, 24 Sep 2009 07:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=X1nNlygjpNfNjb8MeE5bKJ3VxHjjHSeQaLx9vtHpcb8=; b=jHuIBtMyZXYaCrE/ovj8QwDGx2d0ay9USaVJ0bljC2K4PKfJ+uaqvFC1uhj/KCLYXY kbN1i/Zli6TnP/nDUvrR+H69i9vZnZT6k5EK+QK62Wm+JrKZFL4pxoTv7leSqnEGO2b1 r296B6C0pSNM465Kflb7ocHYXGryMmFoJXZNM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RTa3A5PDBg6ioZL65slNDb+ciCSBBPworTqUpXtr74TyhBLEgZmKgDzN2GFa1rM0o6 C8x4I2bilIlBK2pV/ukwDzCbvg18mXlg/WRAw1sKLrjoMBhN4POEfcd8/tL114WyVxN9 EHTqO/GCZWssvyip1xui5FU10YvgYjRm4EvIQ= MIME-Version: 1.0 Received: by 10.229.13.7 with SMTP id z7mr1634697qcz.96.1253803961889; Thu, 24 Sep 2009 07:52:41 -0700 (PDT) In-Reply-To: <200909241411.58823.jon@ffconsultancy.com> References: <200909240247.17560.jon@ffconsultancy.com> <4d1b2df20909240514t1ea2d04hd87ba675e4cc929@mail.gmail.com> <200909241411.58823.jon@ffconsultancy.com> Date: Thu, 24 Sep 2009 16:51:45 +0200 Message-ID: <4d1b2df20909240751q3f8b67dbl285788ab6487dcf8@mail.gmail.com> Subject: Re: [Caml-list] OC4MC : OCaml for Multicore architectures From: Philippe Wang To: Jon Harrop Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset=ISO-8859-1 X-Spam: no; 0.00; ocaml:01 arrays:01 pointer:01 ocaml's:01 bindings:01 ocaml:01 malloc:01 2009:98 entrance:98 threads:01 threads:01 wrote:01 stack:01 heap:01 heap:01 On Thu, Sep 24, 2009 at 3:11 PM, Jon Harrop 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