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=1.3 required=5.0 tests=SPF_FAIL 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 011BCBC68 for ; Mon, 18 Sep 2006 15:10:07 +0200 (CEST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8IDA7wB000389 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 18 Sep 2006 15:10:07 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPIsa-0004CV-A2 for caml-list@inria.fr; Mon, 18 Sep 2006 15:09:44 +0200 Received: from bas1-montreal42-1178046298.dsl.bell.ca ([70.55.143.90]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 15:09:44 +0200 Received: from monnier by bas1-montreal42-1178046298.dsl.bell.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Sep 2006 15:09:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Stefan Monnier Subject: Re: The Future Possibility of Concurrent Garbage Collection? Date: Mon, 18 Sep 2006 09:09:21 -0400 Message-ID: References: <891bd3390609150729k27b7acf8rc9b12f1e08eae93@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: bas1-montreal42-1178046298.dsl.bell.ca User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:TIL9jGUu2FoRfN2OyrNWL9MUzI8= Sender: news X-Miltered: at concorde with ID 450E9AAF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 ocaml:01 garbage:01 garbage:01 compile:01 concurrent:03 concurrent:03 interface:05 cases:08 possibility:10 eager:11 end:11 between:12 isn't:13 umontreal:13 > That said, I do understand that a concurrent GC is a big technical > challenge, and I can understand why the ocaml team isn't eager to take > it on right now. > 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 :-( Stefan