From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alain@frisch.fr>
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=none autolearn=disabled 
	version=3.1.3
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by yquem.inria.fr (Postfix) with ESMTP id 0144BBC6B
	for <caml-list@yquem.inria.fr>; Wed,  7 Nov 2007 10:43:02 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAAAD8XMUdQDPIalmdsb2JhbACOewEBAQEHBAYREQc
X-IronPort-AV: E=Sophos;i="4.21,383,1188770400"; 
   d="scan'208";a="3982624"
Received: from smtp20.orange.fr ([80.12.242.26])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 07 Nov 2007 10:43:02 +0100
Received: from me-wanadoo.net (localhost [127.0.0.1])
	by mwinf2003.orange.fr (SMTP Server) with ESMTP id 7BFC11C000B3
	for <caml-list@yquem.inria.fr>; Wed,  7 Nov 2007 10:43:02 +0100 (CET)
Received: from [192.168.1.59] (APuteaux-154-1-25-138.w83-199.abo.wanadoo.fr [83.199.80.138])
	by mwinf2003.orange.fr (SMTP Server) with ESMTP id 0EAA61C000B2;
	Wed,  7 Nov 2007 10:43:02 +0100 (CET)
X-ME-UUID: 20071107094302601.0EAA61C000B2@mwinf2003.orange.fr
Message-ID: <473188A3.4010809@frisch.fr>
Date: Wed, 07 Nov 2007 10:42:59 +0100
From: Alain Frisch <alain@frisch.fr>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Markus Mottl <markus.mottl@gmail.com>
Cc: Loup Vaillant <loup.vaillant@gmail.com>,
	ocaml-users@janestcapital.com,
	Caml mailing list <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] The GC is not collecting... my mistake?
References: <6f9f8f4a0711060451g1219a880gd711d997043b016@mail.gmail.com> <f8560b80711060931h20702a72j918c1f857faa78e1@mail.gmail.com>
In-Reply-To: <f8560b80711060931h20702a72j918c1f857faa78e1@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam: no; 0.00; frisch:01 frisch:01 markus:01 mottl:01 foo:01 foo:01 byte:01 bytecode:01 runtime:01 afaik:01 ocaml:01 bytecode:01 alloc:01 alloc:01 terminates:01 

Markus Mottl wrote:
> If you compile this to native code, running "foo 1" will print "1"
> followed by "2".  If you run "foo 2" it will print "1", then
> "finalized", then "2".  Byte code will only print "1" and "2" in any
> case - hm, weird.

For bytecode, this is an expected behavior: the back-end does not emit 
any information that would allow the runtime system to know which value 
on the stack is still live (at each possible GC point). The behavior in 
native code is an optimization which lets the GC reclaim more memory, 
but AFAIK, this is not specified. The safe assumption is that a value 
identifier forces the value to remain live in all its syntactic scope 
(this is not a formal definition; for instance, a tail call terminates 
the scope of identifiers defined at the call site).

> Obviously, OCaml does not reclaim the tuple during the allocation loop
> even though it could (and IMHO should).  This can introduce
> substantial space leaks as happened to us.

I agree this might be surprising, but since I don't see the behavior 
changing for bytecode anyway, I don't think it is worth dealing with 
this case in native code (any program that relies on the improved 
behavior you ask for would have an unexpected behavior in bytecode).

The proper solution might be to reflect in the syntactic scope your 
desire to see some value reclaimed:

let main2 () =
   let b =
     let a, b = alloc () in
     Gc.finalise finaliser a;
     print_len a;
     b
   in
   (* Here a is no longer visible and can thus be reclaimed. *)
   alloc_loop ();
   print_len b

This works in bytecode as well.


Alain