From: Goswin von Brederlow <goswin-v-b@web.de>
To: Jon Harrop <jon@ffconsultancy.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] OCaml and Boehm
Date: Sun, 12 Apr 2009 05:25:34 +0200 [thread overview]
Message-ID: <877i1qlfip.fsf@frosties.localdomain> (raw)
In-Reply-To: <200904112136.13520.jon@ffconsultancy.com> (Jon Harrop's message of "Sat, 11 Apr 2009 21:36:13 +0100")
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
next prev parent reply other threads:[~2009-04-12 3:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-11 19:17 Ed Keith
2009-04-11 20:36 ` Jon Harrop
2009-04-12 3:25 ` Goswin von Brederlow [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-04-10 20:13 Lukasz Stafiniak
2009-04-11 9:46 ` [Caml-list] " Basile STARYNKEVITCH
2009-04-11 10:42 ` Jon Harrop
[not found] ` <4a708d20904110511o7d390807r3d29400cf96d6f35@mail.gmail.com>
[not found] ` <49E09C2D.4080906@starynkevitch.net>
2009-04-11 14:11 ` Lukasz Stafiniak
2009-04-11 14:27 ` Jon Harrop
2009-04-11 14:40 ` Lukasz Stafiniak
2009-04-11 20:40 ` Jon Harrop
2009-04-11 15:03 ` Basile STARYNKEVITCH
2009-04-11 20:41 ` Jon Harrop
2009-04-13 9:42 ` Christoph Bauer
2009-04-13 13:15 ` Lukasz Stafiniak
2009-04-14 5:25 ` Goswin von Brederlow
2009-04-12 3:34 ` Goswin von Brederlow
2009-04-12 12:09 ` Lukasz Stafiniak
2009-04-13 17:36 ` Xavier Leroy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877i1qlfip.fsf@frosties.localdomain \
--to=goswin-v-b@web.de \
--cc=caml-list@yquem.inria.fr \
--cc=jon@ffconsultancy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox