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=1.1 required=5.0 tests=AWL,SPF_NEUTRAL 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 577D1BC6B for ; Wed, 7 Nov 2007 16:36:58 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAP5pMUdA6aa1mGdsb2JhbACDJotWAQEBAQcCBhMY X-IronPort-AV: E=Sophos;i="4.21,385,1188770400"; d="scan'208";a="19036188" Received: from py-out-1112.google.com ([64.233.166.181]) by mail4-smtp-sop.national.inria.fr with ESMTP; 07 Nov 2007 16:36:57 +0100 Received: by py-out-1112.google.com with SMTP id u52so4465253pyb for ; Wed, 07 Nov 2007 07:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=y3EEhCfDzRV0B2+6378cVKVAGV+Wuf8l7tjyXEF38RE=; b=NFXPP2FMzBlzWxCnopEtf3jqvL2btmp1UiHp5Q1uEojjB10n06C19p91bVIFlPlHrMR9xX8LadGgmpsYJ5hyYLVx+iUYGwuqhD7wiqfSD8CjMdLzwKlBiA1mQr4MrYc91sUTkCh0N/vz5NKdVLWpoHDbgoSo1hfgkI0swKS/5BU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SgcQYVp6FyYGh6Fzhq0FIUBHqebkJ3JoTySKDiEENqugZsNwOhNh1vKl6ZkgQ6OpnV0mp8m2uVWlx5vc/er8JoOtxHPH91dcnXPm3a4HsAAbE9+P2BYSzj9DDD5jW02uRgi6FJ3MJRHOflI6m3QaBBwHdnDFg3kj2Rc44bIMJx8= Received: by 10.65.52.1 with SMTP id e1mr1926120qbk.1194449815276; Wed, 07 Nov 2007 07:36:55 -0800 (PST) Received: by 10.65.147.12 with HTTP; Wed, 7 Nov 2007 07:36:55 -0800 (PST) Message-ID: Date: Wed, 7 Nov 2007 10:36:55 -0500 From: "Markus Mottl" To: "Alain Frisch" Subject: Re: [Caml-list] The GC is not collecting... my mistake? Cc: "Loup Vaillant" , "Caml mailing list" In-Reply-To: <473188A3.4010809@frisch.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6f9f8f4a0711060451g1219a880gd711d997043b016@mail.gmail.com> <473188A3.4010809@frisch.fr> X-Spam: no; 0.00; markus:01 mottl:01 markus:01 mottl:01 frisch:01 frisch:01 expr:01 expr:01 bytecode:01 bytecode:01 byte:01 byte:01 undecidable:01 violate:01 ocaml:01 On 11/7/07, Alain Frisch wrote: > 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). The situation is actually even worse than that, e.g.: let _, b = expr in ... In the case above the first element of the tuple and the tuple itself that "expr" evaluate to will remain live until "b" is accessed even though they are not bound to names. This is certainly very unintuitive behavior. One would at least expect that values that never get bound and aren't reachable through other bound values aren't considered live. > 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). At least what concerns us we are not overly concerned about optimal behavior in byte code, because everybody that cares about performance (also memory-wise) uses native code anyway. I personally wouldn't mind if byte code behaved differently wrt. GC-behavior. > The proper solution might be to reflect in the syntactic scope your > desire to see some value reclaimed: True, but this quickly becomes cumbersome, and the user may easily forget to do it in all places. Space leaks are generally extremely hard to spot. It seems like an easy thing to do to implement the intuitive notion that a bound variable is considered live in an expression if it occurs freely in this expression. This is still not perfect, because liveness analysis is generally undecidable. But it surely comes close to the heuristics that humans probably use to reason about liveness in their code and would thus not violate their expectations. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com