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: Sun, 12 Oct 2008 16:59:05 +0100 Message-ID: <49dd78620810120859t44cb78f3q46a19f472db2ec45@mail.gmail.com> References: <47B2A8DF.9070004@tammer.net> <87hc8lw0q2.fsf_-_@gnu.org> <49dd78620809271120j17097ffq4da8f2b8dffd4efd@mail.gmail.com> <87abdsf337.fsf@gnu.org> <49dd78620809301510q173d1777rd26240ce40f204f0@mail.gmail.com> <49dd78620810021530u8f29699x88fa8c0241105a07@mail.gmail.com> <87d4ide4md.fsf@gnu.org> <49dd78620810061611v2e67d646v29b479ca1fb23274@mail.gmail.com> <49dd78620810091553gbb10a0aod55076f5eb93b28b@mail.gmail.com> <87k5cfujwl.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1223827166 7854 80.91.229.12 (12 Oct 2008 15:59:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Oct 2008 15:59:26 +0000 (UTC) Cc: guile-devel@gnu.org To: "=?ISO-8859-1?Q?Ludovic_Court=E8s?=" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Oct 12 18:00:23 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 1Kp3Mj-0002I9-Jn for guile-devel@m.gmane.org; Sun, 12 Oct 2008 18:00:21 +0200 Original-Received: from localhost ([127.0.0.1]:41021 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kp3Lf-0002zm-6E for guile-devel@m.gmane.org; Sun, 12 Oct 2008 11:59:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kp3LY-0002zI-PE for guile-devel@gnu.org; Sun, 12 Oct 2008 11:59:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kp3LY-0002z6-CC for guile-devel@gnu.org; Sun, 12 Oct 2008 11:59:08 -0400 Original-Received: from [199.232.76.173] (port=43380 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kp3LY-0002yw-2m for guile-devel@gnu.org; Sun, 12 Oct 2008 11:59:08 -0400 Original-Received: from rv-out-0708.google.com ([209.85.198.240]:22847) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kp3LX-0000OX-7e for guile-devel@gnu.org; Sun, 12 Oct 2008 11:59:07 -0400 Original-Received: by rv-out-0708.google.com with SMTP id k29so1499855rvb.6 for ; Sun, 12 Oct 2008 08:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=HclSr1G/15IMkYiKvRGPVAd/XajySpXmvKEYFA8hdCA=; b=GMuoRP8xmlx8uH9Kp3AtHAGh7mfAHAEAVzLjOHheVQXMOFyJA0PczLoa5UFGQcvFZ9 wfgym9w1WBryG8+i0jnqaep2gKnn+ZBpSgDT3tzOmEHV/gNwB5c/2qNqw8yH6S/cccVA MmrzLQFqYHspfz9sjOReS/kvQ8SaBU37uZzFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=VzqhXdouYAXC6MJmsz4rleYLLfBEkidy2REVkopp3x5MytHZ2Cvdr7oCxPwfqniNta AKlGJ0NmKQzelo5v9G9pA4zMJgroRTRv4MXKJtpNhDia2IpFAQAKBaZbUipDC3UOPEOQ FRyPlwgp3hdEqONZoep5hwoeJJkUWFckVLyYQ= Original-Received: by 10.141.37.8 with SMTP id p8mr2937275rvj.256.1223827145987; Sun, 12 Oct 2008 08:59:05 -0700 (PDT) Original-Received: by 10.141.177.4 with HTTP; Sun, 12 Oct 2008 08:59:05 -0700 (PDT) In-Reply-To: <87k5cfujwl.fsf@gnu.org> Content-Disposition: inline X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:7771 Archived-At: Hi Ludovic, 2008/10/11 Ludovic Court=E8s : > > The approach looks good to me. It's just annoying that > `SCM_CHECK_STACK' (adding a slight overhead) and "threads.h" have to be > modified. > > Instead of storing the high water mark in threads, could we have > `%get-stack-depth' and call it from somewhere deep in the code (similar > to what was in your previous patch)? Here's how my thought process went, in response to this. I only record because I think it's ultimately quite amusing (at my own expense!)... Goodness, that Ludovic, can't he ever just be happy with what I've proposed= ... ...he does have a point though, there could be a performance impact of the high water mark tracking... (and also, FWIW, I'm a bit worried about the number of times we call pthread_getspecific() in mainline code - is that efficient?) ...perhaps the high water marking tracking could be global, instead of per thread; that would avoid adding a field to the thread structure, and would still solve the main problem... ...oh, but that would require a mutex [which is vastly more inefficient]... ...well perhaps we could have an optional callout to Scheme, and do the tracking in Scheme; then in the mainline case we'd still only be checking one variable for being non-null, and the detail of whether it's per thread, or if we need a mutex, can be delegated to the Scheme code... ...oh but hang on, we already have arbitrary callouts to Scheme: the evaluator traps! So yes, I think we can actually do this without any change to the C code except adding %get-stack-depth, by using an evaluator trap. > In that case, instead of using a void port for the REPL's output, we > could for instance use a soft port and measure the stack depth from > there: > > (let ((before (%get-stack-depth)) > (after #f) > (port (make-soft-port (vector (lambda (chr) > (set! after (%get-stack-depth))) > (lambda (str) > (set! after (%get-stack-depth))) > (lambda () > (set! after (%get-stack-depth))) > #f #f #f)))) > (with-output-to-port port > (lambda () > (with-input-from-string "\n" top-repl))) > (abs (- after before))) Cunning idea, but I'm pretty sure it wouldn't be effective, because the reports from people who have seen Stack overflow during 'make check' show that it occurs in a chain of module using: (top-repl) - (use-modules (ice-9 debug)) - ... - before the REPL reaches the point of printing anything. Evaluator traps, on the other hand, will catch everything. (At the cost of running very slowly, but I think that's OK for just this one calibration step.) >> BUILT_SOURCES =3D cpp_err_symbols.c cpp_sig_symbols.c libpath.h \ >> version.h scmconfig.h \ >> - $(DOT_X_FILES) $(EXTRA_DOT_X_FILES) >> + $(DOT_X_FILES) $(EXTRA_DOT_X_FILES) stack-limit-calibration.scm > > As Greg suggested, this could be in `check_DATA' or something like that. Yes, but thanks for the more specific hint! >> +;; This is the value of top-repl-hwm-measured that we get on a >> +;; `canonical' build platform. (See text below for what that means.) >> +(define top-repl-hwm-i386-gnu-linux 9184) > > I'd tend to use the actual GNU triplet, like `i386-pc-linux-gnu'. OK, will do. > Thanks for working on it! Thanks for not being happy! Neil