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.6 required=5.0 tests=RCVD_NUMERIC_HELO,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 C23D7BC68 for ; Tue, 19 Sep 2006 02:10:06 +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 k8J0A5Xr016035 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 19 Sep 2006 02:10:06 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GPTBU-0007i8-KA for caml-list@inria.fr; Tue, 19 Sep 2006 02:09:56 +0200 Received: from 70.130.65.161 ([70.130.65.161]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 02:09:56 +0200 Received: from monnier by 70.130.65.161 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Sep 2006 02:09:56 +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 20:09:47 -0400 Message-ID: References: <891bd3390609150729k27b7acf8rc9b12f1e08eae93@mail.gmail.com> <450EA25B.50505@imperium.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 70.130.65.161 User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:Rex/krn3HjLZOrE8VQ0S2+gjeSQ= Sender: news X-Miltered: at concorde with ID 450F355D.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; compilation:01 admittedly:01 garbage:01 garbage:01 algorithm:01 algorithm:01 implemented:02 programming:03 concurrent:03 concurrent:03 compiled:04 meant:05 frankly:09 sufficiently:10 possibility:10 >> The main cost of a concurrent GC is that the application code has to be >> changed to cooperate with the GC. > Frankly, I don't think so. Lorenz Huelsbergen and Phil Winterbottom > implemented their VCGC algorithm [1] for the Limbo programming language > under Inferno and for SMLNJ as well, and their use of that concurrent > garbage collection algorithm required no changes to any Limbo or SMLNJ > application code. I meant *compiled* application code, of course. I.e. you can't change the GC after compilation. Admittedly, the VCGC algorithm is sufficiently non-intrusive on the mutator that it might be OK to pay its cost even when not using the VCGC algorithm. Stefan