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 05256BBAF for ; Mon, 22 Nov 2010 19:38:11 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQAAFhH6kwSB0QlmWdsb2JhbACiYRUBAQEBAQgLCgcRIrUZiGmFSwSEWg X-IronPort-AV: E=Sophos;i="4.59,237,1288566000"; d="scan'208";a="79992011" Received: from dmz-mailsec-scanner-8.mit.edu ([18.7.68.37]) by mail4-smtp-sop.national.inria.fr with ESMTP; 22 Nov 2010 19:38:10 +0100 X-AuditID: 12074425-b7c98ae000000a04-be-4ceab8915821 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id FD.4A.02564.198BAEC4; Mon, 22 Nov 2010 13:38:09 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id oAMIc8x3011150 for ; Mon, 22 Nov 2010 13:38:09 -0500 Received: from department-of-alchemy.mit.edu (DEPARTMENT-OF-ALCHEMY.MIT.EDU [18.9.64.20]) (authenticated bits=56) (User authenticated as jfc@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id oAMIc7Lq027138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 22 Nov 2010 13:38:08 -0500 (EST) Received: (from jfc@localhost) by department-of-alchemy.mit.edu (8.12.9.20060308) id oAMIc7Yt021756; Mon, 22 Nov 2010 13:38:07 -0500 (EST) Message-Id: <201011221838.oAMIc7Yt021756@department-of-alchemy.mit.edu> To: OCaml mailing list Subject: Re: [Caml-list] Optimizing garbage collection In-Reply-To: Date: Mon, 22 Nov 2010 13:38:07 -0500 From: John Carr X-Brightmail-Tracker: AAAAARawQDQ= X-Spam: no; 0.00; uniformly:01 allocator:01 garbage:01 garbage:01 heap:01 heap:01 caml-list:01 minor:01 minor:01 short:01 reuse:01 reuse:01 data:02 functional:02 reward:96 > 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? I don't understand "smooth". Minor heap size should be based on the rate of garbage generation relative to allocation to balance cache misses with GC cost. The ratio may be small or large independent of whether it varies during the program. The default minor heap size is well tuned for traditional functional programming behavior: high rate of allocation, short lifetime. When memory access is smaller than a cache line the cache does not reward data reuse so much as address reuse. Collecting a small minor heap that is mostly garbage allows the allocator to start over at an address that is already in cache. Continuing to allocate instead of collecting leads to write-allocate misses.