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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id A62EABBC1 for ; Fri, 7 Mar 2008 18:05:38 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYCAO4E0UfAXQInh2dsb2JhbACDIY1XAQEBCAopgQ2Sa4cF X-IronPort-AV: E=Sophos;i="4.25,463,1199660400"; d="scan'208";a="9110151" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 07 Mar 2008 18:05:38 +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 m27H5aGP009698 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 7 Mar 2008 18:05:38 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8BAAMF0UdA6aq9mGdsb2JhbACDIY1XAQEBAQEGBAQJChiBDZJqhwU X-IronPort-AV: E=Sophos;i="4.25,463,1199660400"; d="scan'208";a="23494667" Received: from rn-out-0910.google.com ([64.233.170.189]) by mail4-smtp-sop.national.inria.fr with ESMTP; 07 Mar 2008 18:05:37 +0100 Received: by rn-out-0910.google.com with SMTP id i50so921242rne.11 for ; Fri, 07 Mar 2008 09:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=pdDRNRG5FsgFi2ZhusVuvMQoj1a2a/crVdO5oR3DJzE=; b=ROdQAI/3VDcG12+uN0IqpkFe8Lms4bTAAY9UIKsMIXsDSMWTeBfhvbZyIn7n9Egth/czZkAWCe8MICmEQ/Krryy+fhubHDjsaKngAdq/3e0f6V1jYvpEpR+Fpr2JJE8mL+rYyG93wwdJnoBpu+X/BkPIiit+zytAVpLMiT3higU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MI6oPVcUxW6a1aNXhoV8AUTpUVaurdxw/q4GYM8lssx0UImZmuntFRjmw3OZIRsxCwUl75y+RN8WNCm+Vil0KgkpFCryN5wlAiQ6MYRyqJrhSW6pWDeTBOzA+yKSDrB5nGR+TiutN1gf0WC76BgSn3dLQKd0kuZwEOaio8cB9uI= Received: by 10.142.213.9 with SMTP id l9mr807141wfg.104.1204909536007; Fri, 07 Mar 2008 09:05:36 -0800 (PST) Received: by 10.142.102.3 with HTTP; Fri, 7 Mar 2008 09:05:35 -0800 (PST) Message-ID: Date: Fri, 7 Mar 2008 12:05:35 -0500 From: "Markus Mottl" To: "Xavier Leroy" Subject: Re: [Caml-list] Global roots causing performance problems Cc: ocaml , ocaml-users@janestcapital.com In-Reply-To: <47D14CBD.4060207@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47D14CBD.4060207@inria.fr> X-Miltered: at concorde with ID 47D175E0.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; markus:01 mottl:01 markus:01 mottl:01 pointer:01 pointer:01 bindings:01 lablgtk:01 semantics:01 generational:01 programmer's:01 bindings:01 berke:01 generational:01 ocaml:01 On Fri, Mar 7, 2008 at 9:10 AM, Xavier Leroy wrote: > 1- Change the specs of caml_register_global_root() to prohibit > in-place updates to the value contained in the registered value > pointer. If programmers need to do this, they must un-register the > value pointer, update its contents, then re-register it. > How much existing code would that break? I don't know. I have just looked at a fairly large number of bindings. Only a few actually register global roots, and those that do would be perfectly safe - with the exception of LablGTK it seems. I'm a bit wary of changing the semantics of global root registration in a way that could seriously break existing libraries even though almost all of them seem fine. > 2- Keep the current API for backward compatibility and add a > caml_register_global_immutable_root() function that would implement > generational scanning of global roots, in exchange for the > programmer's guarantee that the values contained in those roots are > never changed. Then, convince authors of Caml-C bindings to use the > new API. After having given it some thought, I think I prefer this approach. As a maintainer of some C-bindings that would be affected by this change, I'd be perfectly happy to upgrade them, which seems like extremely little work. I also second Berke Durak's proposal to add some kind of modification macro/function. Concerning the naming we should maybe avoid the name "immutable" then, because one can obviously update the value, but has to do so explicitly. How about "caml_(un)register_generational_root" and "caml_modify_generational_root"? > I'm willing to implement any of these 2 approaches, but it is not a > transparent change in either case. Thanks a lot, this would be great! Best regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com