From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Han-Wen Nienhuys Newsgroups: gmane.lisp.guile.devel Subject: Re: GUILE_MAX_HEAP_SIZE Date: Wed, 13 Aug 2008 12:04:10 -0300 Message-ID: References: <87ej4tmf4m.fsf@gnu.org> Reply-To: hanwen@xs4all.nl NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1218640372 24216 80.91.229.12 (13 Aug 2008 15:12:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Aug 2008 15:12:52 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Aug 13 17:13:44 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KTI2c-0004TN-0h for guile-devel@m.gmane.org; Wed, 13 Aug 2008 17:13:38 +0200 Original-Received: from localhost ([127.0.0.1]:44656 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTI1f-0005Ml-H6 for guile-devel@m.gmane.org; Wed, 13 Aug 2008 11:12:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KTHuu-0002qB-RV for guile-devel@gnu.org; Wed, 13 Aug 2008 11:05:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KTHut-0002pC-0o for guile-devel@gnu.org; Wed, 13 Aug 2008 11:05:40 -0400 Original-Received: from [199.232.76.173] (port=37605 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTHus-0002p7-QW for guile-devel@gnu.org; Wed, 13 Aug 2008 11:05:38 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:59368 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KTHur-0006sh-Ig for guile-devel@gnu.org; Wed, 13 Aug 2008 11:05:38 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KTHul-00072l-1y for guile-devel@gnu.org; Wed, 13 Aug 2008 15:05:31 +0000 Original-Received: from 201.80.3.52 ([201.80.3.52]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Aug 2008 15:05:31 +0000 Original-Received: from hanwen by 201.80.3.52 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Aug 2008 15:05:31 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 37 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 201.80.3.52 User-Agent: Thunderbird 2.0.0.16 (X11/20080723) In-Reply-To: <87ej4tmf4m.fsf@gnu.org> X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7425 Archived-At: Ludovic Courtès escreveu: > Hi Han-Wen, > > Han-Wen Nienhuys writes: > >> I've implemented an env var GUILE_MAX_HEAP_SIZE (- some lilypond users >> were complaining that running lily on large sets of files keeps >> growing the heap forever, leading to trashing). > > Of course, the correct fix would be to help the GC be more reasonable, > as it's currently somewhat broken: > > http://thread.gmane.org/gmane.lisp.guile.devel/6699/focus=6832 > > You could also try setting `GUILE_MAX_SEGMENT_SIZE' to a smaller value, > as suggested there: > > http://thread.gmane.org/gmane.lisp.guile.devel/6699/focus=6836 I'll have a think about this. Perhaps we can add a more stateful approach to the GC thresholds. >> Please comment on the patch; it's in branch dev/hanwen on >> sv.git.gnu.org > > The patch contains mostly unrelated indentation changes, can you fix > that? Sure. > Also, it gives me the impression that we've definitely lost control over > the GC code, and we're adding yet another configuration variable to work > around that. :-( I'm not against initing it automatically to something like RAM * 0.8 or something, but that would run into portability issues. In the end, the amount of RAM available is something that the current GC does not factor in, so it will happily grow the heap beyond that. -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen