From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 8EBD7BC48 for ; Wed, 9 Mar 2005 14:21:45 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j29DLjmY010587 for ; Wed, 9 Mar 2005 14:21:45 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA13202 for ; Wed, 9 Mar 2005 14:21:45 +0100 (MET) Received: from [128.93.8.130] (macadam.inria.fr [128.93.8.130]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j29DLiwW010580 for ; Wed, 9 Mar 2005 14:21:44 +0100 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: <293072a520e3724a0497e6456a8675be@mac.com> <200503071729.20117.jon@jdh30.plus.com> <877e9a1705030710476502ad31@mail.gmail.com> <200503080110.21839.jon@jdh30.plus.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Damien Doligez Subject: Re: [Caml-list] Re: Re: exception safety / RAII ? Date: Wed, 9 Mar 2005 14:21:51 +0100 To: caml users X-Mailer: Apple Mail (2.619.2) X-Miltered: at nez-perce with ID 422EF869.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 422EF868.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; damien:01 damien:01 caml-list:01 afaik:01 dependencies:01 garbage:01 garbage:01 ocaml:01 dependencies:01 wrote:01 exception:01 incremental:01 doligez:01 doligez:01 functions:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Mar 8, 2005, at 23:53, Daniel Yokomizo wrote: > AFAIK it doesn't force the GC to respect the dependencies. A object is > garbage if it can't be reached from any root references, it doesn't > matter > if other garbage objects still reference it. So if we have: > > > ROOT -> A -> B -> C > > D -> E -> F > > G -> B > > H -> C > > > the GC can collect any of [D, E, F, G, H], in any order it wants, > because > they're all garbage. An incremental collector could collect first [F, > G, H] > because they are (say) large objects, and don't recycle the memory for > [D, > E] until the next collection. As far as _collecting_ is concerned, the GC can do it in any order it wants, and the current implementation is likely to do it in order of increasing addresses (i.e. in some unpredictable order). > IIUC the current OCaml GC implementation may exhibit such properties > (i.e. > respect dependencies) but it isn't required to do so. What I did specify and implement for 3.08 is the following: If you call Gc.finalise on your values in the same order as they are allocated, and if you don't introduce new depedencies afterward (with assignments), then the finalisation functions will be called in the right order (i.e. D before E before F, etc). On the other hand, it means that a non-terminating finalisation function must call Gc.finalise_release in order to let the GC run other finalisation functions. -- Damien