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 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 8170CBBAF for ; Sun, 12 Apr 2009 05:25:38 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMCAK/74EnZSMDji2dsb2JhbACBUJRiAQEBCgsKBw8FsRqDfAY X-IronPort-AV: E=Sophos;i="4.38,431,1233529200"; d="scan'208";a="27528181" Received: from fmmailgate02.web.de ([217.72.192.227]) by mail1-smtp-roc.national.inria.fr with ESMTP; 12 Apr 2009 05:25:38 +0200 Received: from smtp07.web.de (fmsmtp07.dlan.cinetic.de [172.20.5.215]) by fmmailgate02.web.de (Postfix) with ESMTP id B5E72FCDAE87; Sun, 12 Apr 2009 05:25:37 +0200 (CEST) Received: from [78.43.226.218] (helo=frosties.localdomain) by smtp07.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #277) id 1LsqK9-0000VA-00; Sun, 12 Apr 2009 05:25:37 +0200 Received: from mrvn by frosties.localdomain with local (Exim 4.69) (envelope-from ) id 1LsqK8-00044b-8c; Sun, 12 Apr 2009 05:25:36 +0200 From: Goswin von Brederlow To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OCaml and Boehm References: <321060.19886.qm@web54109.mail.re2.yahoo.com> <200904112136.13520.jon@ffconsultancy.com> Date: Sun, 12 Apr 2009 05:25:34 +0200 In-Reply-To: <200904112136.13520.jon@ffconsultancy.com> (Jon Harrop's message of "Sat, 11 Apr 2009 21:36:13 +0100") Message-ID: <877i1qlfip.fsf@frosties.localdomain> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX1/YAeNbLA++oMCRKM0t3aYcIv4wb7zeVVF5aRix Q7ZSzVi6A0dkwu78SNgv/ZkSvpd9H1OC0Bqg1Za1dHe6FfBCp3 CTJ6AULdo= X-Spam: no; 0.00; ocaml:01 boehm:01 ocaml:01 boehm:01 incorrectly:01 pointers:01 pointers:01 pointer:01 kees:01 2009:98 stays:98 mfg:98 wrote:01 wrote:01 rec:01 Jon Harrop writes: > On Saturday 11 April 2009 20:17:58 Ed Keith wrote: >> --- On Sat, 4/11/09, Jon Harrop wrote: >> > From: Jon Harrop >> > Subject: Re: [Caml-list] OCaml and Boehm >> > To: caml-list@yquem.inria.fr >> > Date: Saturday, April 11, 2009, 10:27 AM >> > >> > Also, don't forget that many people incorrectly claim that smart pointers >> > deallocate at the earliest possible point when, in fact, they typically >> > keep values alive longer than necessary. >> >> Could elaborate on this? I'm having a hard time envisioning a situation >> where GC could free memory that smart pointers would not free. > > Smart pointers deallocate when values fall out of scope. GC deallocates when > it runs and values are unreachable. > > Consider: > > let () = > let x = .. > f x > g() > > The value "x" stays in scope to the end of the block so a smart pointer will > not deallocate it. The GC may well run during "g", realise that "x" is > unreachable and deallocate it. > > Note that there are further unwanted side effects of smart pointers here. > Specifically, having to keep "x" around until the end of scope increases > register pressure and makes it more likely to values will be spilled, which > is a substantial performance cost. How about cyclic records: type r = { next : r } let rec r1 { next = r2 } and r2 = { next = r1 } Smart pointers will never free that since r1 kees r2 alive and r2 keeps r1 alive. MfG Goswin