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=AWL autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 8B0E8BBCA for ; Sun, 11 May 2008 06:21:10 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUDAM4QJkjUnw7Wb2dsb2JhbACCMY9YAQwFAgQHEwOXLw X-IronPort-AV: E=Sophos;i="4.27,467,1204498800"; d="scan'208";a="26041048" Received: from ptb-relay03.plus.net ([212.159.14.214]) by mail4-smtp-sop.national.inria.fr with ESMTP; 11 May 2008 06:21:04 +0200 Received: from [80.229.56.224] (helo=beast.local) by ptb-relay03.plus.net with esmtp (Exim) id 1Jv33W-0003o0-90 for caml-list@yquem.inria.fr; Sun, 11 May 2008 05:21:03 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Ancient, concurrency, etc. Date: Sun, 11 May 2008 05:15:52 +0100 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805110515.52809.jon@ffconsultancy.com> X-Plusnet-Relay: 650222053a4617f612465d043c721440 X-Spam: no; 0.00; berke:01 durak:01 mutation:01 ocaml:01 run-time:01 pointer:01 pointer:01 marshaling:01 ocaml:01 memcpy:01 hashing:01 ocaml's:01 hashing:01 syntax:01 10,:98 On Saturday 10 May 2008 10:09:04 Berke Durak wrote: > On Sat, May 10, 2008 at 10:51 AM, Richard Jones wrote: > > There are various restrictions on mutating the ancient data, which are > > explained in the README. It is not true that ancient data is > > completely immutable, just that you really need to understand what > > you're doing in order to do it correctly. > > I'm not talking of mutating atomic values here. I assume Richard was referring to injecting references from the ancient heap into the live heap using mutation. If the value were later moved on the live heap then the OCaml run-time would not know to update the pointer in the ancient heap and you would get a dangling pointer. > I'm saying that you certainly can't have the GC or someone else mutate the > data for traversal purposes. I believe the GC will never try to traverse it so it will not mutate it. > > I'm not sure what this means. I haven't tried to Marshal ancient > > data, because ancient data can already be persisted, so marshaling it > > doesn't make much sense. > > 'Deep copying' of ancient data can be done just like deep copying any > > other OCaml value. > > As in: it can't be done polymorphically, unless you resort to Marshal, > which doesn't work on ancient data. Or memcpy. > > because they make the assumption that anything outside the normal > > OCaml heap is incomparable > > And that can be quite annoying, so we'd like a way to take values of out > the ancient heap. This is exactly the incidental complexity I was referring to. > > , but you can certainly write your own > > comparison functions to replace those, eg. comparing > > character-by-character for strings. > > Not. Polymorphic. Use memcmp. :-) > > This has nothing to do with 'marking'. > > Well, walking over a value graph, either for complete > hashing/comparison/copying or > serialization requires marking unless your graph is a tree. Not really. There are two problems here. Firstly, OCaml's built in hashing, comparison and equality blindly recurse without checking for cycles so they do not need any metadata. Secondly, you can store the traversal data outside the graph: there is no need to mark it. > > So it seems that adding a generic copy-out-of-the-ancient heap function > > > > > (which marks in a private area) would be worthwhile. Should not be too > > > difficult. > > > > As I said earlier, you can just copy values from the ancient heap as > > you would any other value, eg. using { ... with ... } syntax or > > Array.copy / String.copy etc. > > That is not polymorphic. If we have a type: type t = { x: float; n: int } with a value of that type in the ancient heap and we do: let local = { ancient with n=3 } then we have created a shallow copy that has now pulled a pointer to the boxed float value in the ancient heap into our GC which will later try to deallocate that float and crash. Is that correct? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e