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 98205BBCA for ; Tue, 13 May 2008 11:18:59 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8AAL/5KEjBL1AZo2dsb2JhbACSDwEBAQEBCAUIBxGZew X-IronPort-AV: E=Sophos;i="4.27,478,1204498800"; d="scan'208";a="26107660" Received: from gw.exalead.com (HELO exalead.com) ([193.47.80.25]) by mail4-smtp-sop.national.inria.fr with ESMTP; 13 May 2008 11:18:59 +0200 Received: from [192.168.204.148] (madpc064.exalead.com [192.168.204.148]) (authenticated bits=0) by exalead.com (8.14.2/8.14.0) with ESMTP id m4D9Itpt012778; Tue, 13 May 2008 11:18:57 +0200 Message-ID: <48295CFF.80202@exalead.com> Date: Tue, 13 May 2008 11:18:55 +0200 From: Berke Durak User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Christophe Raffalli Cc: Caml Mailing List Subject: Re: [Caml-list] From ancient to a third Generation References: <48288A41.4030501@univ-savoie.fr> In-Reply-To: <48288A41.4030501@univ-savoie.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; berke:01 durak:01 berke:01 durak:01 christophe:01 raffalli:01 runtime:01 pointer:01 reformulate:01 run-time:01 ocaml:01 pointer:01 pointers:01 traversing:01 surviving:98 Christophe Raffalli wrote: > What do you think ? I understand that, after noticing that objects in the ancient heap are manually allocated and deleted, you thought about making the ancient heap garbage-collected. So far so good. > - Objects are moved to this third generation either manually (or created > there) or automatically after surviving k major GC (k may be ajustable at > runtime ? k = 0 means never ?) Moving them manually, or by a call to "share" seems more appropriate. We don't want to unnecessarily clutter a permanent heap. > - There is a global greyval table, protected by a mutex, and an object > must be added in the table of greyval when mutated if it is a pointer > pointing to the major or minor heap of a specific process. Then, the object > stops to be accessible for reading by other processes (Here there is room to > change the design ...). I don't understand this paragraph, could you reformulate? What do you mean by "stops being accessible"? How is this checked? Wouldn't that require extra run-time checks? > - This third generation could be dealf with be a daemon I like this idea. It's a little bit like the Java server VM idea, except that it just manages memory. > and accessible by processes written using different languages ... Well, if by processes written using different language you mean languages bound to C code using the Ocaml macros... > - Objects in the third generation are collected by a reference counter + > a specific GC: the counter counts the number of processes > holding at least one pointer to this object from their own stack, major > or minor heap. This counter is only increased/decreased by the GC of > each process > (a mutex is neeeded here). There is also a specific GC process (mark and > sweep ?). To take care of pointers from the third generation to the > third generation > and make sure that object with a zero counter can be removed. I see a few problems: a) The daemon will need to ask all the accessing processes to mark their ancient values before collecting. b) What about cycles traversing multiple heaps? Maybe that's what your obscure paragraph was talking about. c) What representation will the values in the third generation use? If you need extra GC information (such as a refcounter), you will add significant overhead to values: you will need at least an extra word per block header. -- Berke DURAK