[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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