From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p190m6Kp022393 for ; Wed, 9 Feb 2011 01:48:06 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUEAOFyUU1V2gB4h2dsb2JhbACXJY4yAQEBCgsIGiS9FA2FTQSPMw X-IronPort-AV: E=Sophos;i="4.60,444,1291590000"; d="scan'208";a="99526118" Received: from emailfrontal1.citycable.ch ([85.218.0.120]) by mail1-smtp-roc.national.inria.fr with SMTP; 09 Feb 2011 01:48:06 +0100 X-Alinto-smtpauth-localdomain: Yes Received: from seldon (unknown [85.218.92.99]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal1.citycable.ch (Postfix) with ESMTPA id 0B9EA12C153; Wed, 9 Feb 2011 01:48:05 +0100 (CET) Received: from yziquel by seldon with local (Exim 4.72) (envelope-from ) id 1PmyCO-00044U-5l; Wed, 09 Feb 2011 01:46:24 +0100 Date: Wed, 9 Feb 2011 01:46:24 +0100 From: Guillaume Yziquel To: orbitz@ezabel.com Cc: caml-list@inria.fr Message-ID: <20110209004623.GF12473@localhost> References: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com> User-Agent: Mutt/1.5.20 (2009-06-14) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p190m6Kp022393 Subject: Re: [Caml-list] Scoped Bound Resource Management just for C++? Le Tuesday 08 Feb 2011 à 18:57:37 (-0500), orbitz@ezabel.com a écrit : > One of the benefits, in my opinion, of C++ is SBRM. You can reason > about the lifetime of an object and have an give yourself guarantees > about its clean up. The method of initialization and clean up are > also consistent for every object in the language. I assume you're talking about destructions of temporaries and auto variables in C++. To me, the main benefit of this appears when you're in a procedurally oriented language and when the language idiom allows you to pass your objects in registers when they are small enough, or relying on compiler optimisations to avoid copying the objects over and over between function calls. The downside is that as soon as you're crossing boundaries between libraries or putting things on the freestore, there is copying involved, and not-so-clear memory management semantics. > My questions are: > 1) Do other people in the FP world consider this to be a good > strategy? Not to my opinion. To me, the way OCaml manages the garbage collection of the minor heap seems to me a more practical way of doing things and not an inefficient one. Moreover, SBRM makes memory management semantics not so easy to reason about when integrating C++ with an another language or another runtime (callbacks from C++ for instance). > 2) Can this be done in a sane way in a GCd language? Nothing stops you from managing the lifecycle of your values explicitely, but I do not think you'd reap the benefits above. Moreover, from a GC point of view, I do not see how to implement an SBRM-friendly scheme compatible with heap compacting GC algorithms like the modified Cheney algorithm used in OCaml. For integral types, you have SBRM quite for free in OCaml, but anything more complex either gets optimised away if possible, or gets quickly heap allocated (much more likely). > 3) What are the alternatives in a language like Ocaml? I think you would also have a typing issue in a language such as OCaml. Having SBRM-managed values means not being able to constructs lists with them or things like that. So each time you call a function with such a value in parameter, you'd need the compiler to guarantee that it would not try to heap allocate it. Otherwise, you're back with copying the value. I think your question depends on what kind of datatypes you're interested in, what kind of lifecycle you expect from your values, and what runtime benefits you expect of it. If your value is short-lived, it is allocated on the minor heap, never moves from there, and garbage collection of the minor heap is very fast. That's the closest you can get, I guess. But you do not have guarantees of it being garbage collected, unless you trigger manually garbage collection of the minor heap (which may be costly if done in an unreasonable manner). > Thanks! -- Guillaume Yziquel