From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Configure GMP to use GC allocation functions, remove bignum finalizers Date: Mon, 28 Nov 2011 23:23:08 +0100 Message-ID: <87r50ranub.fsf@pobox.com> References: <87tycaodlk.fsf@netris.org> <87k4d6edvr.fsf@gnu.org> <8739jue9wk.fsf@neil-laptop.ossau.uklinux.net> <87zkfh9x8r.fsf@pobox.com> <8762i5mf4x.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1322519011 8472 80.91.229.12 (28 Nov 2011 22:23:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2011 22:23:31 +0000 (UTC) Cc: guile-devel@gnu.org, Neil Jerram To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Nov 28 23:23:26 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RV9bi-0000Ft-1Q for guile-devel@m.gmane.org; Mon, 28 Nov 2011 23:23:26 +0100 Original-Received: from localhost ([::1]:53905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RV9bh-0003Dk-IW for guile-devel@m.gmane.org; Mon, 28 Nov 2011 17:23:25 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:45279) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RV9bd-0003AH-0Q for guile-devel@gnu.org; Mon, 28 Nov 2011 17:23:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RV9bb-0007Lf-Mp for guile-devel@gnu.org; Mon, 28 Nov 2011 17:23:20 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:44393 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RV9bb-0007LL-IE; Mon, 28 Nov 2011 17:23:19 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 5DB7D7408; Mon, 28 Nov 2011 17:23:18 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=qxWSFOF07peA fY+XUC0T3UTStFc=; b=bA7TX/EtCd8AnpOcoNei3QXFgOACIVWqAYfdj+kbuDhW nnakbvXIXE4AWyN/hbeHm8YTnPEZbFvx+80Qm0IepADwtijRJoJHEQWwPyqaVgr6 pDwHoui6bSkNFTd4tgsEn5sdmEOTJ2URLw/yonuGf0b2nKg3u4C00YcVmtQ5kZk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=KFO7md o+tgn1nlwPm2hTATByaeLStwF46nE+DjZP2SjsqJp3njc1MxdjL7iXg0UOaOmYTq AGutC4pYfymqxt3EwAR5nCQXTluU1Iq6mcR34OIYHm6KDSnzkpm/naGKA0IZB5JN OVF/NRZcjq3aFUqwaZDOyjkXr3P21vu3uHujk= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 5241D7406; Mon, 28 Nov 2011 17:23:18 -0500 (EST) Original-Received: from badger (unknown [91.117.99.191]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 60C827405; Mon, 28 Nov 2011 17:23:16 -0500 (EST) In-Reply-To: <8762i5mf4x.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Sun, 27 Nov 2011 22:25:50 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-Pobox-Relay-ID: 9179A07A-1A0F-11E1-A15A-65B1DE995924-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 74.115.168.62 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12938 Archived-At: On Sun 27 Nov 2011 22:25, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > The problem is that this measurement doesn=E2=80=99t allow us to differen= tiate > between a growing heap with objects that may be freed as a result of > running the GC, and a growing heap just because the application needs > more malloc=E2=80=99d objects. This is true, but typically the heap stabilizes at some point. Here is the problem: if you are allocating at a GC-managed heap size H, garbage collection will tend to limit your process image size to H*N. But if at the same time you are mallocating at a rate M bytes per GC-allocated byte, then your process stabilizes at H*N*M -- assuming that collecting data will result in malloc'd data being freed. It doesn't take a very large M for this to be a bad situation. If you would like to limit your image size, you should GC more often -- the bigger the M, the more often. The original iterative factorial case that Mark gave is pessimal, because M is an increasing function of time. Now, what happens if the process is not growing because of GC, but for other reasons? In that case M will be estimated as artificially high for a while, and so GC will happen more often on the Guile side. But when it stabilizes, we can ease back the GC frequency. The key is to measure process image growth, not mallocation rate. I'm going to give this a try and see what happens. Andy --=20 http://wingolog.org/