Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] OCaml and Boehm
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Goswin von Brederlow <goswin-v-b@w...>
Subject: Re: [Caml-list] OCaml and Boehm
Jon Harrop <jon@ffconsultancy.com> writes:

> On Saturday 11 April 2009 20:17:58 Ed Keith wrote:
>> --- On Sat, 4/11/09, Jon Harrop <jon@ffconsultancy.com> wrote:
>> > From: Jon Harrop <jon@ffconsultancy.com>
>> > 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