From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q099NTJY028018 for ; Mon, 9 Jan 2012 10:23:33 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwCANGxCk/RVdY2c2dsb2JhbABDrEEIIgEMCgwHFAQhgXIBAQEDARICJgYBGx4DAQsGBQspEiMRAQUBHBkih1gCmQcKi2mCb4Q8P4hxAgULiGyDGgSNS4c9AYcGhnw9g3w X-IronPort-AV: E=Sophos;i="4.71,479,1320620400"; d="scan'208";a="126061863" Received: from mail-bk0-f54.google.com ([209.85.214.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 09 Jan 2012 10:23:30 +0100 Received: by bkbzv15 with SMTP id zv15so2761474bkb.27 for ; Mon, 09 Jan 2012 01:23:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=oYZe+JpaAkj8QnUUPbznm5NnHX9FL9qAMG88rzlN+Co=; b=TRnDJqpsEH7Nbjtox/5yeq+4zkVZc8Z153+pd6tFyN5FUQZ3QCrsvinOuG9iNJZcE2 rBanwTYr7QAgYMWMiRm8SeEfNhk5I8mDlpm1v+F4Xoj16C1G2AmaDmf6ziYiTeASXG9W NoF5NwU0tbnoUHHLTDEqYdpphiNfKGk4Q/hTE= Received: by 10.204.9.208 with SMTP id m16mr6972400bkm.34.1326101009463; Mon, 09 Jan 2012 01:23:29 -0800 (PST) Received: from cherry.local.tld ([213.169.92.77]) by mx.google.com with ESMTPS id ci12sm141990309bkb.13.2012.01.09.01.23.28 (version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 01:23:28 -0800 (PST) Date: Mon, 9 Jan 2012 11:23:24 +0200 From: ygrek To: caml-list@inria.fr Message-Id: <20120109112324.d553ddd2.ygrekheretix@gmail.com> In-Reply-To: <1326094398.2242.26.camel@samsung> References: <1326094398.2242.26.camel@samsung> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Non-toplevel C functions using OCaml values On Mon, 09 Jan 2012 08:33:18 +0100 Gerd Stolpmann wrote: > If you are looking for more optimizations, you can also replace the > first Store_field with Field(newblock,0) = Val_int(h). Store_field is > slightly more expensive, because there is a test whether you create a > pointer from the old generation to the young generation, which is only > allowed if this pointer is added to a special list. You only assign an > int here, so it cannot be a pointer. > > For the second assignment you need Store_field because there is no > (official) guarantee that newblock is created in the young generation > (although I don't see a reason why newblock could ever reside in the old > generation, but it's really dependent on implementation details in the > GC). AFAIK the better (and described in manual) way is to use caml_alloc_small and direct assignment into fields in this case. To answer OP's question: CAML* macros are used to live in harmony with GC, and GC manages ocaml heap. So one should always use these macros when (and by the same rules) the code touches values in ocaml heap - no matter whether the function is called directly from ocaml side or not. -- ygrek http://ygrek.org.ua