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=0.0 required=5.0 tests=AWL 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 2E087BBC1; Fri, 7 Mar 2008 15:52:19 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMAACLl0EfBL1AZjGdsb2JhbACQeAEBAQgEBgkGGoENmXY X-IronPort-AV: E=Sophos;i="4.25,463,1199660400"; d="scan'208";a="23488618" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 07 Mar 2008 15:52:19 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m27EqD42030727 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK); Fri, 7 Mar 2008 15:52:18 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMAACLl0EfBL1AZjGdsb2JhbACQeAEBAQgEBgkGGoENmXY X-IronPort-AV: E=Sophos;i="4.25,463,1199660400"; d="scan'208";a="23488617" Received: from gw.exalead.com (HELO exalead.com) ([193.47.80.25]) by mail4-smtp-sop.national.inria.fr with ESMTP; 07 Mar 2008 15:52:18 +0100 Received: from [192.168.204.148] (madpc064.exalead.com [192.168.204.148]) (authenticated bits=0) by exalead.com (8.14.0/8.14.0) with ESMTP id m27EqG92032634; Fri, 7 Mar 2008 15:52:16 +0100 Message-ID: <47D156A0.5010701@exalead.com> Date: Fri, 07 Mar 2008 15:52:16 +0100 From: Berke Durak User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Xavier Leroy Cc: Markus Mottl , ocaml-users@janestcapital.com, ocaml Subject: Re: [Caml-list] Global roots causing performance problems References: <47D14CBD.4060207@inria.fr> In-Reply-To: <47D14CBD.4060207@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at discorde with ID 47D1569D.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 durak:01 berke:01 durak:01 generational:01 pointer:01 overwritten:01 pointer:01 extensively:01 nodes:01 semantics:01 generational:01 programmer's:01 bindings:01 imho:01 Xavier Leroy a écrit : Hello, > This "generational" approach is the natural solution to the problem > you mention. However, it is not compatible with the current API for > global root registration: when a program registers a "value *" pointer > using caml_register_global_root(), the program is free to change the > value contained in that placeholder at any time without notifying the > Caml memory manager. As a consequence, the minor GC has no choice but > scanning all global roots every time, because any of them could have > been overwritten with a freshly-allocated Caml block since the > previous minor GC. > > There are 2 ways to go about this problem: > > 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'm using caml_register_global_root extensively in Aurochs when building the parse tree, and updating it in-place (consing a list of children nodes, actually.) If you change the semantics of caml_register_global_root() it would be nice to have a caml_modify_global_root() macro that does what is needed. > 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. That's the better solution IMHO, as it won't break existing code and gives a clear migration path to better performance and improved customer satisfaction. > I'm willing to implement any of these 2 approaches, but it is not a > transparent change in either case. -- Berke DURAK