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=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr 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 7D66BBC68 for ; Tue, 19 Sep 2006 11:19:49 +0200 (CEST) Received: from smeltpunt.science.ru.nl (smeltpunt.science.ru.nl [131.174.16.145]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8J9JljF027856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Sep 2006 11:19:49 +0200 Received: from tandem.cs.ru.nl [131.174.142.18] (helo=tandem.cs.ru.nl) by smeltpunt.science.ru.nl (8.13.7/5.9) with ESMTP id k8J9Hv9X014377 for ; Tue, 19 Sep 2006 11:19:47 +0200 (MEST) Received: from tews by tandem.cs.ru.nl with local (Exim 4.63) (envelope-from ) id 1GPble-0003eS-7C for caml-list@inria.fr; Tue, 19 Sep 2006 11:19:50 +0200 From: Hendrik Tews To: caml-list@inria.fr Subject: Re: [Caml-list] Re: The Future Possibility of Concurrent Garbage Collection? References: <891bd3390609150729k27b7acf8rc9b12f1e08eae93@mail.gmail.com> Date: Tue, 19 Sep 2006 11:19:50 +0200 In-Reply-To: (Stefan Monnier's message of "Mon, 18 Sep 2006 09:09:21 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.56 on 131.174.16.145 X-Miltered: at concorde with ID 450FB633.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; hendrik:01 tews:01 tews:01 ocaml:01 compiler:01 inlining:01 hendrik:01 garbage:01 garbage:01 compile:01 caml-list:01 writes:01 disables:02 defined:02 concurrent:03 Stefan Monnier writes: > The ocaml team could document the GC interface and modularize > everything, such that the user can choose between different > garbage collectors (at compile time, or even better at > application start). The main cost of a concurrent GC is that the application code has to be changed to cooperate with the GC. So if you want to be able to use the same application code for both the concurrent and the non-concurrent GC, you end up paying the price of concurrent GC in both cases :-( For a start it would be sufficient to have a compiler switch that disables all inlining of GC operations and uses some well defined library interface instead. Nobody would have to pay anything then. Optizing performance bottemlacks can wait until the first alternative garbage collector is out. Hendrik