Re: [Caml-list] Scoped Bound Resource Management just for C++?

[Guillaume Yziquel <guillaume.yziquel@citycable.ch>]

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