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 0C3CEBC68; Tue, 26 Sep 2006 17:01:52 +0200 (CEST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8QF1pl3028928; Tue, 26 Sep 2006 17:01:51 +0200 Received: from [84.58.161.77] (helo=gate.lan.gerd-stolpmann.de) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GSERN1pg4-0008WV; Tue, 26 Sep 2006 17:01:46 +0200 Received: from flakew.lan.gerd-stolpmann.de (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id 55866C35C; Tue, 26 Sep 2006 17:01:38 +0200 (CEST) Subject: Re: [Caml-list] Regarding SMP computing From: Gerd Stolpmann To: Markus Mottl Cc: Damien Doligez , quant@janestcapital.com, caml users In-Reply-To: References: <4517C7FE.8080102@mcmaster.ca> <20060925194153.GA20467@furbychan.cocan.org> Content-Type: text/plain Date: Tue, 26 Sep 2006 17:01:33 +0200 Message-Id: <1159282893.29248.29.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:a6865a839c0178d9aa0ce41878507ea2 X-Miltered: at concorde with ID 451940DF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; gerd:01 stolpmann:01 markus:01 mottl:01 damien:01 damien:01 ocaml:01 rework:01 runtime:01 pointers:01 ocaml-heap:01 pointers:01 ocaml-heap:01 pointer:01 ocaml-value:01 Am Dienstag, den 26.09.2006, 10:37 -0400 schrieb Markus Mottl: > On 9/26/06, Damien Doligez wrote: > > The GC doesn't work by checking whether something has become > > unreachable. It works by marking all reachable data, then deallocating > > everything else. There is no way to do what you want in OCaml, and > > I don't think it can be done without a major rework of the runtime > > system. > > But isn't it true that the GC doesn't follow pointers that point > outside the OCaml-heap? In that case it might be conceivable to copy > OCaml-data that must not be reclaimed into the C-heap. Of course, > this would mean that pointers must not point back into the OCaml-heap > from there, because there is no way the GC could know then that some > value in the OCaml-heap is still in use, or how to update the pointer > in the C-heap in case the OCaml-value gets moved around, e.g. during a > compaction. That sounds perfectly compatible with the current GC approach. All what you need to do is to add a third, "very old" generation. Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------