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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 89669BBC1 for ; Fri, 7 Mar 2008 15:10:06 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBANjb0EfAXQInh2dsb2JhbACQeAEBAQgKKYENmXg X-IronPort-AV: E=Sophos;i="4.25,463,1199660400"; d="scan'208";a="8121632" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 07 Mar 2008 15:10:06 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m27EA5Xw001580 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 7 Mar 2008 15:10:06 +0100 X-IronPort-AV: E=Sophos;i="4.25,463,1199660400"; d="scan'208";a="9996144" Received: from estephe.inria.fr (HELO [128.93.11.95]) ([128.93.11.95]) by mail3-relais-sop.national.inria.fr with ESMTP; 07 Mar 2008 15:10:05 +0100 Message-ID: <47D14CBD.4060207@inria.fr> Date: Fri, 07 Mar 2008 15:10:05 +0100 From: Xavier Leroy User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Markus Mottl Cc: ocaml , ocaml-users@janestcapital.com Subject: Re: [Caml-list] Global roots causing performance problems References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 47D14CBD.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; runtime:01 generational:01 pointer:01 overwritten:01 pointer:01 generational:01 programmer's:01 bindings:01 heap:01 heap:01 caml-list:01 minor:01 minor:01 immutable:01 caml:02 > [GC overhead of having many global memory roots] > We therefore wonder whether it wouldn't be much more effective to fix > the runtime. I don't know the exact details of how things currently > work, but I guess that it would be possible to have two separate sets > of global roots for the minor and major heap. Then, once a value gets > oldified, the global root, too, could wander to the corresponding set. > The set for the major heap could then be scanned only once per full > major cycle, maybe even in slices, too. Would this suggestion be easy > to implement? 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. 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. I'm willing to implement any of these 2 approaches, but it is not a transparent change in either case. - Xavier Leroy