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,HTML_MESSAGE autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id A013DBC6B for ; Mon, 10 Dec 2007 22:16:12 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKs7XUfAXQInh2dsb2JhbACCcoxzAQEBCAop X-IronPort-AV: E=Sophos;i="4.24,148,1196636400"; d="scan'208,217";a="20182522" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 10 Dec 2007 22:16:10 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id lBALG9pL025060 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 10 Dec 2007 22:16:10 +0100 X-IronPort-AV: E=Sophos;i="4.24,148,1196636400"; d="scan'208,217";a="20182520" Received: from smtpoutm.mac.com ([17.148.16.75]) by mail4-smtp-sop.national.inria.fr with ESMTP; 10 Dec 2007 22:16:08 +0100 Received: from mac.com (asmtp003-s [10.150.69.66]) by smtpoutm.mac.com (Xserve/smtpout012/MantshX 4.0) with ESMTP id lBALG7bi024951 for ; Mon, 10 Dec 2007 13:16:07 -0800 (PST) Received: from [192.168.8.101] (c-24-218-151-219.hsd1.ma.comcast.net [24.218.151.219]) (authenticated bits=0) by mac.com (Xserve/asmtp003/MantshX 4.0) with ESMTP id lBALG1nk010336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 10 Dec 2007 13:16:02 -0800 (PST) Message-Id: From: Gordon Henriksen To: caml-list@inria.fr In-Reply-To: <20071210202738.GA15084@furbychan.cocan.org> Content-Type: multipart/alternative; boundary=Apple-Mail-84--29176330 Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Caml-list] Ask for a more efficient way to deallocate memory (full version) Date: Mon, 10 Dec 2007 16:15:55 -0500 References: <39980.81.57.198.61.1197236388.squirrel@webmail.lpn.cnrs.fr> <95513600712091355j35c4fa65g40bbfce02303796a@mail.gmail.com> <475D2210.70708@Lpn.cnrs.fr> <1197304401.475d6a51d9c06@webmail.in-berlin.de> <20071210202738.GA15084@furbychan.cocan.org> X-Mailer: Apple Mail (2.915) X-Miltered: at concorde with ID 475DAC99.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0100,:01 bandel:01 ocaml:01 foo:01 gc'd:01 descriptors:01 orthogonal:01 runtime:01 runtimes:01 runtimes:01 tackled:01 rtti:01 retrain:01 ocaml:01 expr:01 --Apple-Mail-84--29176330 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Dec 10, 2007, at 15:27, Richard Jones wrote: > On Mon, Dec 10, 2007 at 05:33:21PM +0100, Oliver Bandel wrote: > >> Zitat von Fabrice Pardo : >> >>> When using these kind of external C functions, OCaml seems then =20 >>> less comfortable to the programmer than reference counted languages. >> >> I doubt that reference-count is the reason here. perl also uses =20 >> reference count, but Filehandles and Dirhandles have to be closed =20 >> with close / closedir. > > This isn't true. In Perl file handles are closed at the end of a =20 > scope if they are no longer used. In other words a Perl-equivalent =20= > to this loop will never use more than a single file descriptor: > > while (true) { > open "foo" > } > > Even in a GC'd language which could finalize the file handle you =20 > could never be sure when the GC is going to be called so it could =20 > use an indefinite number of file descriptors. > > There is a really good paper on this subject -- how ref counting and =20= > garbage collection are orthogonal language concepts -- but I can't =20 > find it right now. True. To address the original point, however: This is a significant problem that crops up frequently in language/=20 runtime designs, especially when migrating to static, garbage =20 collected runtimes from scripting runtimes. parrot tackled this =20 problem; they call it timely collection and went far out of their way =20= to implement it, performing miniature collections when a resource =20 variable goes out of scope. This is rather expensive. The practical reality is that, short of re-engineering memory =20 management, developers migrating from C++ (RTTI) and scripting =20 languages may need to retrain themselves to recognize that: finalization does not provide a time bound on destruction garbage collection manages memory and no other resources C# provides a convenient using construct to ease the pain, but Java =20 code is littered with finally blocks for this reason. Ocaml is hampered in that its try block has no native finally =20 construct, which requires repetition in the normal flow-of-control and =20= exceptional cases. Implementing reusable using constructs with filters =20= and closures for each type of resource is the best option I've seen, =20 although a generic finally construct is also possible also using =20 closures: let finally expr cleanup =3D try let result =3D expr () in cleanup (); result with x -> cleanup (); raise x Unfortunately, this is not at all attractive at the call site. =97 Gordon --Apple-Mail-84--29176330 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Dec 10, 2007, at = 15:27, Richard Jones wrote:

On Mon, = Dec 10, 2007 at 05:33:21PM +0100, Oliver Bandel = wrote:

Zitat von Fabrice Pardo <Fabrice.Pardo@Lpn.cnrs.fr>= ;:

When using these kind of = external C functions, OCaml seems then less = comfortable to the programmer than reference counted = languages.

I doubt that = reference-count is the reason here. perl also uses reference = count, but Filehandles and Dirhandles have to be closed with close = / closedir.

This isn't true.  In Perl file = handles are closed at the end of a scope if they are no longer = used.  In other words a Perl-equivalent to this loop will = never use more than a single file descriptor:

 while (true) = {
   open "foo"
 }

Even in a GC'd = language which could finalize the file handle you could never be = sure when the GC is going to be called so it could use = an indefinite number of file descriptors.

There is a really = good paper on this subject -- how ref counting and garbage = collection are orthogonal language concepts -- but I can't find it = right now.

True. To address the = original point, however:

This is a significant = problem that crops up frequently in language/runtime designs, especially = when migrating to static, garbage collected runtimes from scripting = runtimes. parrot tackled this problem; they call it timely collection = and went far out of their way to implement it, performing miniature = collections when a resource variable goes out of scope. This is rather = expensive.

The= practical reality is that, short of re-engineering memory management, = developers migrating from C++ (RTTI) and scripting languages may need to = retrain themselves to recognize that:

  • finalization does not provide a time bound on = destruction
  • garbage collection manages memory and no other = resources

C# provides a convenient = using construct = to ease the pain, but Java code is littered with finally blocks for = this reason.

Ocaml is hampered in that = its try block has no native finally construct,= which requires repetition in the normal flow-of-control and exceptional = cases. Implementing reusable using constructs with filters and closures for = each type of resource is the best option I've seen, although a generic = finally = construct is also possible also using closures:

let finally expr cleanup = =3D
  try
    let result =3D expr () = in
    cleanup ();
   =  result
  with x ->
    cleanup = ();
    raise x

Unfortunately, this is not = at all attractive at the call site.

=97 Gordon

= --Apple-Mail-84--29176330--