From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: stack calibration Date: Mon, 30 Mar 2009 21:43:36 +0100 Message-ID: <87d4bypwqv.fsf@arudy.ossau.uklinux.net> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1238445868 29165 80.91.229.12 (30 Mar 2009 20:44:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Mar 2009 20:44:28 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Mar 30 22:45:45 2009 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 1LoOMX-0002Gn-TV for guile-devel@m.gmane.org; Mon, 30 Mar 2009 22:45:42 +0200 Original-Received: from localhost ([127.0.0.1]:41131 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LoOLA-0007oJ-Cw for guile-devel@m.gmane.org; Mon, 30 Mar 2009 16:44:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LoOKe-0007Jx-4c for guile-devel@gnu.org; Mon, 30 Mar 2009 16:43:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LoOKZ-0007GR-Nj for guile-devel@gnu.org; Mon, 30 Mar 2009 16:43:43 -0400 Original-Received: from [199.232.76.173] (port=58442 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LoOKZ-0007G7-Hv for guile-devel@gnu.org; Mon, 30 Mar 2009 16:43:39 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:52933) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LoOKY-0003V5-U3 for guile-devel@gnu.org; Mon, 30 Mar 2009 16:43:39 -0400 Original-Received: from arudy (host86-157-180-39.range86-157.btcentralplus.com [86.157.180.39]) by mail3.uklinux.net (Postfix) with ESMTP id CEBDA1F69B8; Mon, 30 Mar 2009 21:43:37 +0100 (BST) Original-Received: from arudy.ossau.uklinux.net (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 0B5A23801E; Mon, 30 Mar 2009 21:43:36 +0100 (BST) In-Reply-To: (Andy Wingo's message of "Fri\, 27 Mar 2009 14\:19\:28 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 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:8352 Archived-At: Andy Wingo writes: > Hey Guilers, Hi Andy, In summary, I'm not sure I'm following the logic here... > The recent commit to compile with the stack calibration file, > 7ca96180f00800414a9cf855e5ca4dceb9baca07, breaks compilation because the > compile scripts have hash-bang lines like this: > > #!/bin/sh > # -*- scheme -*- > exec ${GUILE-guile} -e '(@ (scripts compile) compile)' -s $0 "$@" > !# FWIW, I think this kind of incantation is really horrible. Ditto for usage of "guile-tools ...". What kind of a scripting language is it that needs to be bootstrapped by a different language? Anyway, I see the breakage... (Probably almost any change would break something so fragile.) > Also, it is a bit irritating to have to load a file just so Guile won't > be broken (exaggerated wording, but I think that's what it is.) I think you may be misunderstanding. stack-limit-calibration.scm should make precisely 0 difference on the "canonical build platform" - which in practice means ia32 GNU/Linux. As Guile stands (and notwithstanding your idea that we could use getrlimit instead), we do hardcode _some_ stack depth limit. Once that was 20k, then 40k, and you're now suggesting 60k. Those are supposed to be values that will work on the canonical platform. stack-limit-calibration.scm is all about scaling down/up the hardcoded value for a non-canonical platform that might use more or less stack on average than the canonical platform - e.g. because it has fewer registers, because its pointers are twice the size (ia64) etc. The primary purpose of stack-limit-calibration.scm is to allow "make check" to succeed on those platforms, and it now makes sense to generalize that to any other guile-using operations that we run during the build - such as compiling. It would probably also make sense to install stack-limit-calibration.scm, so that 3rd party programs could also use it; but we don't currently do that. > So I have a proposal. We should set the stack limit to 60k words. If we need 60k on the canonical build platform, we should have 60k. No issue there. > Pros: 1) This way Guile will just work. (For you. Other platforms may still need stack-limit-calibration.scm.) > 2) It's simple. > 3) We avoid the evaluator this way. > > Cons: 1) A stack-consuming process will take longer to catch. Not a problem. Any individual program can set the stack limit differently, if they so choose. > I cannot think of any other cons. GC just marks between the stack base > and the stack pointer anyway. This would be 500 kB on x86-64, but a > normal program would never use that, and last time I looked processes > had 2 MB of stack by default anyway. It would be 250 kB on Linux. > > If we were really concerned about processes actually consuming all of > their stack, we should use a value from getrlimit(2) instead. I don't think that is the concern. I think the idea is to catch incorrectly written (i.e. usually non-tail-recursive) programs before they crash. Regards, Neil