From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p0VGaoiU021855 for ; Mon, 31 Jan 2011 17:36:50 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FAL9zRk2ty1O7/2dsb2JhbACWV44ic703hU4EhROKUw X-IronPort-AV: E=Sophos;i="4.60,404,1291590000"; d="scan'208";a="98944021" Received: from elehack.net ([173.203.83.187]) by mail1-smtp-roc.national.inria.fr with ESMTP; 31 Jan 2011 17:36:45 +0100 Received: from [134.84.74.203] (x-134-84-74-203.uofm-secure.wireless.umn.edu [134.84.74.203]) by elehack.net (Postfix) with ESMTPSA id DC110C8D24 for ; Mon, 31 Jan 2011 10:37:05 -0600 (CST) Message-ID: <4D46E51A.8010907@elehack.net> Date: Mon, 31 Jan 2011 10:36:42 -0600 From: Michael Ekstrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: caml-list@inria.fr References: <476C4EB3-59D2-4756-927C-C1697E7AE4D8@math.harvard.edu> In-Reply-To: <476C4EB3-59D2-4756-927C-C1697E7AE4D8@math.harvard.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] reference cells On 01/31/2011 10:29 AM, Nicolas Ojeda Bar wrote: > I am translating an imperative language into Ocaml. Right now I am > translating mutable variables into ref cells. Will they be optimized > when I compile the corresponding Ocaml program? Or will they be heap > allocated? If this is the case, I will have to translate my language > into some sort of SSA form before, and I would like to avoid that. Most of them will be heap-allocated. They may stay on the minor heap if they're short-lived, so they may never hit the major heap (and thus incur higher GC overhead), but they'll be on the heap. I believe the compiler has optimizations to unbox some refs, particularly for ints and floats, but for heap-allocated structures I believe it will produce heap allocated references. Further, mutating references can be a relatively expensive operation. In order to support the major-minor heap scheme, modifying a reference that points to a non-integral value (anything that's heap allocated) involves checking some tables to see where the reference and referenced object are. This is to keep track of all references in the major heap which have been changed to point to objects on the minor heap. Int refs can avoid this problem, as integers are not stored on the heap, but for anything more complex (including boxed floats), you incur the caml_modify overhead. This is true not only for references, but also for mutable fields and array cells. - Michael