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: advice on reducing C stack frame size? Date: Sat, 13 Sep 2008 15:48:37 -0300 Message-ID: References: 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: 7bit X-Trace: ger.gmane.org 1221331843 25852 80.91.229.12 (13 Sep 2008 18:50:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Sep 2008 18:50:43 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Sep 13 20:51:38 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 1KeaDW-0000nH-Kt for guile-devel@m.gmane.org; Sat, 13 Sep 2008 20:51:34 +0200 Original-Received: from localhost ([127.0.0.1]:41796 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KeaCV-00043P-R5 for guile-devel@m.gmane.org; Sat, 13 Sep 2008 14:50:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KeaCQ-00041w-3a for guile-devel@gnu.org; Sat, 13 Sep 2008 14:50:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KeaCN-0003zA-UN for guile-devel@gnu.org; Sat, 13 Sep 2008 14:50:24 -0400 Original-Received: from [199.232.76.173] (port=59520 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KeaCN-0003z2-Of for guile-devel@gnu.org; Sat, 13 Sep 2008 14:50:23 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:35776 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 1KeaCN-000365-Fg for guile-devel@gnu.org; Sat, 13 Sep 2008 14:50:23 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KeaCF-0004NI-5D for guile-devel@gnu.org; Sat, 13 Sep 2008 18:50:15 +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 ; Sat, 13 Sep 2008 18:50:15 +0000 Original-Received: from hanwen by 201.80.3.52 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 13 Sep 2008 18:50:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 40 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: X-detected-operating-system: by monty-python.gnu.org: GNU/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:7685 Archived-At: Andy Wingo escreveu: > Hi, > > With a local patch, it seems that my C stack frames are getting large > enough to start hitting the stack overflow checks. > > (In the future this won't be a terrible problem, as you won't be > recursively calling the evaluator the the vm then the evaluator etc too > much, but while we still have a fair amount of code being interpreted, > it is important.) > > So for example, just sitting at the repl, we have: > > frame (I think). It is about 20 kilobytes!!! In contrast, a deval frame > appears to be less, but still excessive: > > #19 0x0014b076 in deval (x=0xb7f3a478, env=0xb7ee2560) at eval.i.c:358 > 358 (void) EVAL (form, env); > (gdb) > #20 0x0014e72e in scm_dapply (proc=0xb7f3a6d0, arg1=, args=0xb7ee25d0) at eval.i.c:1858 > 1858 RETURN (EVALCAR (proc, args)); > (gdb) p 0x0014e72e - 0x0014b076 > $5 = 14008 > > This is with gcc 4.3.0 20080428 (Red Hat 4.3.0-8). > > My question is: what should I do about this? Wait for the runtime tuning > patches to land in master and then merge them? Assume that over time, I This looks like a bug or an oversight. - 14k is about 3500 SCM values; we surely don't have that many local variables, so it looks as if there might be some macro that expands into a local array. I'd have a look at the addresses of the different local variables to see where all that memory is going. Also, look at the preprocessed source and scan for array variables. -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen