From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr 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 C297FBBAF for ; Mon, 22 Nov 2010 17:27:30 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcAAN8o6kzVBIoSkWdsb2JhbACUVYdngQADhTMBAQEBCQsKBxEEHr08gwUIgj4Eil4 X-IronPort-AV: E=Sophos;i="4.59,236,1288566000"; d="scan'208";a="79983391" Received: from impaqm2.telefonica.net (HELO telefonica.net) ([213.4.138.18]) by mail4-smtp-sop.national.inria.fr with ESMTP; 22 Nov 2010 17:27:29 +0100 Received: from IMPmailhost4.adm.correo ([10.20.102.125]) by IMPaqm2.telefonica.net with bizsmtp id aEFb1f01b2iL0W23MGTUVo; Mon, 22 Nov 2010 17:27:28 +0100 Received: from NANA.localdomain ([88.6.14.255]) by IMPmailhost4.adm.correo with BIZ IMP id aGTT1f00b5WAhSo1kGTUpP; Mon, 22 Nov 2010 17:27:28 +0100 X-Brightmail-Tracker: AAAAAA== X-original-sender: ferferse@telefonica.net Received: from mfp by NANA.localdomain with local (Exim 4.69) (envelope-from ) id 1PKZEl-0006hX-HS for caml-list@inria.fr; Mon, 22 Nov 2010 17:27:27 +0100 Date: Mon, 22 Nov 2010 17:27:27 +0100 From: Mauricio Fernandez To: caml-list@inria.fr Subject: Re: [Caml-list] Optimizing garbage collection Message-ID: <20101122162727.GA1796@NANA.localdomain> Mail-Followup-To: caml-list@inria.fr References: <4CE68FAB.6020102@elehack.net> <577267187.967802.1290367612809.JavaMail.root@zmbs1.inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Spam: no; 0.00; 0100,:01 damien:01 eray:01 ozkural:01 uniformly:01 26,:98 dime:98 doligez:01 garbage:01 wrote:01 wrote:01 heap:01 heap:01 caml-list:01 minor:01 On Mon, Nov 22, 2010 at 04:10:49PM +0100, Damien Doligez wrote: > On 2010-11-21, at 20:26, Eray Ozkural wrote: > > > I've been thinking whether some kind of doubling strategy would work for the minor heap size. What do you think? > > Sounds like an interesting idea, but what heuristic would you use? > When everything is smooth, the running time decreases something like > exponentially with the minor heap size, so you'd always want to > increase the size. How do you tell when to stop? And then, if the > program is not behaving uniformly, when do you decide to reduce > the size? Just dropping an idea, not sure it's worth a dime... How about an exponential growth scheme with hysteresis? On each minor collection, multiply the size by a if the rate of promoted words exceeds r1, divide by b if the rate is below r2 (r1 > r2); otherwise remain stable. In order to account for the effect of the cache hierarchy, r1 and r2 could also be a function of the current heap size (e.g., with r1 and r2 being higher when approaching "magic" numbers such as the size of the L2 cache on the left and right side respectively). It'd also be very nice to be able to estimate the amount of time spent on minor + major GC collection vs. the mutator. -- Mauricio Fernandez - http://eigenclass.org