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: Clearing stale references from the stack Date: Tue, 31 Jan 2012 21:46:02 +0100 Message-ID: <87y5sntxbp.fsf@pobox.com> References: <87wr87eoo4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1328042782 3553 80.91.229.3 (31 Jan 2012 20:46:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 31 Jan 2012 20:46:22 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 31 21:46:21 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RsKar-0002SF-3L for guile-devel@m.gmane.org; Tue, 31 Jan 2012 21:46:21 +0100 Original-Received: from localhost ([::1]:44535 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsKaq-0000CJ-DC for guile-devel@m.gmane.org; Tue, 31 Jan 2012 15:46:20 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:49555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsKai-0000BX-Hx for guile-devel@gnu.org; Tue, 31 Jan 2012 15:46:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsKac-0003ei-L6 for guile-devel@gnu.org; Tue, 31 Jan 2012 15:46:12 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:52905 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsKac-0003ee-D8; Tue, 31 Jan 2012 15:46:06 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id A74BE8E47; Tue, 31 Jan 2012 15:46:05 -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=W30njDJ8dEGw JujUxHBk9d4VWZo=; b=Hsy1tREEmVylMIHZJLBsUSYSQA1FjBKNf+MYLuq8FX8Q Wap3fFWwIon21iK9M6k6h51rIMzbJ0xxr6JdYdT4znL++XV12juK4554BPHlLzdt F5q9kYDPbUFELnMwsKtN4QwwanX+28mC/nUQLZyqCgv7iHLCb8VLX+WwQjEJ3QE= 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=SGH0Wd jyn4UQxamZvfyZEO7U3L6aWsXqCL9wlLrF7uL2je3+BlAUnGASqcWo809zANQcIU cT20oBopXM3+Q6HDznUUucFN7TDThbvpz6Xz+NwApNHGmvR8fHUwnXTJP/7dxTK2 n2fjBP9yuK0DbgT4qxhyuvoIZrCJHIkW67q0g= 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 9F4F98E46; Tue, 31 Jan 2012 15:46:05 -0500 (EST) Original-Received: from badger (unknown [90.164.198.39]) (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 D02B88E44; Tue, 31 Jan 2012 15:46:04 -0500 (EST) In-Reply-To: <87wr87eoo4.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Tue, 31 Jan 2012 19:02:03 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-Pobox-Relay-ID: 980C40E0-4C4C-11E1-B9C3-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:13765 Archived-At: Hello :-) On Tue 31 Jan 2012 19:02, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > "Andy Wingo" skribis: > >> +;; Recurse through a C function that should clear any values that might >> +;; have spilled on the stack temporarily. (The salient feature of >> +;; with-continuation-barrier is that currently it is implemented as a C >> +;; function that recursively calls the VM.) >> +;; >> +(define* (clear-stale-stack-references #:optional (n 10)) >> + (if (positive? n) >> + (with-continuation-barrier >> + (lambda () >> + (clear-stale-stack-references (1- n)))))) >> + >> ;;; Call THUNK with a given locale >> (define (with-locale* nloc thunk) >> (let ((loc #f)) >> diff --git a/test-suite/tests/gc.test b/test-suite/tests/gc.test >> index 97eeb19..1afcea3 100644 >> --- a/test-suite/tests/gc.test >> +++ b/test-suite/tests/gc.test >> @@ -49,13 +49,6 @@ >> ;;;=20 >> ;;; >>=20=20 >> -(define (stack-cleanup depth) >> - ;; Clean up stack space for DEPTH words. This is defined here so that >> - ;; `peval' doesn't inline it. >> - (let cleanup ((i depth)) >> - (and (> i 0) >> - (begin (cleanup (1- i)) i)))) >> - > > Note that =E2=80=981-=E2=80=99 here is a subr call (because =E2=80=98stac= k-cleanup=E2=80=99 is > interpreted), so both procedures may have a similar effect, no? I don't think so. The question for me is, how far up the C stack does this get? For `stack-cleanup' (I have to learn how to type those nice quotes some day), there will never be more than one `1-' frame active on the C stack. With clear-stale-stack-references, there will be `depth' many. I think! Andy --=20 http://wingolog.org/