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 559D3BC68; Wed, 27 Sep 2006 19:35:34 +0200 (CEST) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8RHZXJf002188; Wed, 27 Sep 2006 19:35:34 +0200 Received: from [192.168.1.2] (unknown [82.237.71.191]) by smtp1-g19.free.fr (Postfix) with ESMTP id 5C7532F7B1; Wed, 27 Sep 2006 19:35:33 +0200 (CEST) Message-ID: <451AB64B.4030003@inria.fr> Date: Wed, 27 Sep 2006 19:35:07 +0200 From: Xavier Leroy User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Mottl Cc: Damien Doligez , quant@janestcapital.com, caml users Subject: Re: [Caml-list] out-of-heap data structures [was: Regarding SMP computing] References: <4517C7FE.8080102@mcmaster.ca> <20060925194153.GA20467@furbychan.cocan.org> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 451AB665.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; pointers:01 ocaml-heap:01 ocamlopt:01 initialized:01 heap:01 pointers:01 ocaml-heap:01 pointer:01 ocaml-value:01 compaction:01 ad-hoc:01 marshaling:01 hashing:01 heap:01 ocaml:01 > 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. Yes, this is possible. For instance, ocamlopt places structured constants (e.g. constant lists) in the initialized data section of the executable, outside the Caml 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. ... unless you register the locations of back-pointers as global roots. But be careful that global roots are scanned at every GC (minor as well as major), therefore a large number of such roots slow down the GC significantly. > If the above really works, There is one caveat: ad-hoc polymorphic primitives (structural equality and comparisons, marshaling, hashing) will not work on data structures that reside outside of the Caml heap. The reason is that these primitives treat out-of-heap pointers as opaque data. There is a special case (the "Is_atom" test) for pointers that correspond to ocamlopt-generated static data, but extending this special case is nonobvious. > I'd be glad to know whether there is > already functionality to copy OCaml-structures around. Apparently, Richard Jones is already working on it... Basically, it's just like a copying collection with only one root. You could draw inspiration from the OCaml minor GC (Cheney-style breadth-first copying) and from the marshaller (depth-first quasi-copying). - Xavier Leroy