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 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr 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 08EB5BBC1; Fri, 7 Mar 2008 17:45:37 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBAC4A0UdQRFuwh2dsb2JhbACQeAEBAQgKKYENmXA X-IronPort-AV: E=Sophos;i="4.25,463,1199660400"; d="scan'208";a="9109427" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 07 Mar 2008 17:45:37 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m27GjbGW003041 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK); Fri, 7 Mar 2008 17:45:37 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBAC4A0UdQRFuwh2dsb2JhbACQeAEBAQgKKYENmXA X-IronPort-AV: E=Sophos;i="4.25,463,1199660400"; d="scan'208";a="9109426" Received: from furbychan.cocan.org ([80.68.91.176]) by mail1-smtp-roc.national.inria.fr with ESMTP; 07 Mar 2008 17:45:36 +0100 Received: from rich by furbychan.cocan.org with local (Exim 4.63) (envelope-from ) id 1JXfhJ-0006Ag-R1; Fri, 07 Mar 2008 16:45:29 +0000 Date: Fri, 7 Mar 2008 16:45:29 +0000 To: Xavier Leroy Cc: Markus Mottl , ocaml-users@janestcapital.com, ocaml Subject: Re: [Caml-list] Global roots causing performance problems Message-ID: <20080307164529.GB23233@annexia.org> References: <47D14CBD.4060207@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47D14CBD.4060207@inria.fr> User-Agent: Mutt/1.5.13 (2006-08-11) From: Richard Jones X-Miltered: at discorde with ID 47D17131.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0100,:01 runtime:01 generational:01 pointer:01 overwritten:01 pointer:01 generational:01 programmer's:01 bindings:01 grepping:01 wrote:01 heap:01 heap:01 caml-list:01 minor:01 On Fri, Mar 07, 2008 at 03:10:05PM +0100, Xavier Leroy wrote: > > [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. The second option is much preferable for two reasons: (a) If libraries don't change then at least they don't break. (b) It is possible to update a library by grepping through the source for caml_register_global_root and then examining each call to see if you can prove the new constraint. If you can't be certain, well no sweat, just leave it as it is. Rich. -- Richard Jones Red Hat