From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 70CB5BCAE for ; Fri, 24 Jun 2005 11:36:18 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j5O9aHW3025459 for ; Fri, 24 Jun 2005 11:36:17 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA16722 for ; Fri, 24 Jun 2005 11:36:17 +0200 (MET DST) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.202]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j5O9aGtI001215 for ; Fri, 24 Jun 2005 11:36:17 +0200 Received: by nproxy.gmail.com with SMTP id n15so92318nfc for ; Fri, 24 Jun 2005 02:36:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BO464A7o8ueDAXQA+NbGu4tJupzAAoFF502yJhYCNlu98Ia8F0mrgYw22tj+SU9vK2PAr2q0NOKItAwd3xymTjwabtxSehhXN6nglmCal0Dv0j2TXO0UqSLmB+klepTlUQ2CqIPZToqe63342ximp97M0C5xNxRDxhkjc3Aznjg= Received: by 10.48.237.12 with SMTP id k12mr59867nfh; Fri, 24 Jun 2005 02:36:16 -0700 (PDT) Received: by 10.48.237.20 with HTTP; Fri, 24 Jun 2005 02:36:16 -0700 (PDT) Message-ID: <3d13dcfc050624023670d3aed2@mail.gmail.com> Date: Fri, 24 Jun 2005 11:36:16 +0200 From: David MENTRE To: Jean-Marie Gaillourdet Subject: Re: [Caml-list] How INRIA people envision OCaml's parallel future? Cc: jtbryant@valdosta.edu, caml-list@inria.fr In-Reply-To: <1119603126.8485.4.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <3d13dcfc05062300215e4be9ee@mail.gmail.com> <1119547256.4675.12.camel@starlight.valdosta.edu> <1119603126.8485.4.camel@localhost.localdomain> X-Miltered: at concorde with ID 42BBD411.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42BBD410.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml's:01 garbage:01 threads:01 garbage:01 minor:01 minor:01 caml-list:01 doligez:01 constructor:01 thread:02 thread:02 tuple:02 groups:02 groups:02 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_BY_IP autolearn=disabled version=3.0.2 X-Spam-Level: Hello, 2005/6/24, Jean-Marie Gaillourdet : > I am not a garbage collector specialist, too. But I guess it is much > harder than this. Your idea implies that every allocation requires to > obtain a lock. How often do you allocate memory in a functional > programming language? Quite often, I guess. Every simple tuple, every > constructor application and so on. So you would synchronize all threads > very often. Additionally, during every collection phase, all other cpus > have to wait for the garbage collector. I am pretty sure, that this > would not scale very far. Sorry ;-) One simple solution to this issue would be to have a per thread minor allocation zone, with a global, lock-protected, major zone. For newly allocated objects and minor collection phase, the code is lock-free. But I suspect that interleaving between minor and major phases makes things much more difficult. Maybe dedicating a thread to major collection could be useful (major collection would be blocked by access to minor zone, with priority given to minor zone). Anyway, INRIA people have already worked on those issues and had proposals. It is just that they feel it was not worth the trouble, *at that time*: http://groups.google.com/groups?q=3Ddoligez+parallel+GC+caml-list&hl=3Dfr&l= r=3D&selm=3Dfa.dlqoshv.1a66ho7%40ifi.uio.no&rnum=3D2 Yours, d.