From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: GC crashes Date: 08 Dec 2003 01:25:17 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20031124.110938.193696628.wl@gnu.org> <200311260203.LAA26808@etlken.m17n.org> <20031128.103107.41640217.wl@gnu.org> <200312011240.VAA05762@etlken.m17n.org> <200312022337.IAA02026@etlken.m17n.org> <200312032319.IAA04473@etlken.m17n.org> <200312040112.KAA04711@etlken.m17n.org> <200312040221.LAA04807@etlken.m17n.org> <200312080231.LAA12773@etlken.m17n.org> <200312080501.OAA12954@etlken.m17n.org> <200312080605.PAA13041@etlken.m17n.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070864928 24256 80.91.224.253 (8 Dec 2003 06:28:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 8 Dec 2003 06:28:48 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Dec 08 07:28:44 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATEsu-00061G-00 for ; Mon, 08 Dec 2003 07:28:44 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATEsu-000246-00 for ; Mon, 08 Dec 2003 07:28:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ATFnh-0007iL-AE for emacs-devel@quimby.gnus.org; Mon, 08 Dec 2003 02:27:25 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ATFnb-0007iD-DD for emacs-devel@gnu.org; Mon, 08 Dec 2003 02:27:19 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ATFn5-0007gm-Ix for emacs-devel@gnu.org; Mon, 08 Dec 2003 02:27:18 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ATFn5-0007gj-6Q for emacs-devel@gnu.org; Mon, 08 Dec 2003 02:26:47 -0500 Original-Received: from vor.iro.umontreal.ca (vor.iro.umontreal.ca [132.204.24.42]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 449AF20F7E; Mon, 8 Dec 2003 01:25:18 -0500 (EST) Original-Received: by vor.iro.umontreal.ca (Postfix, from userid 20848) id C2D5F3CFD9; Mon, 8 Dec 2003 01:25:17 -0500 (EST) Original-To: Kenichi Handa In-Reply-To: <200312080605.PAA13041@etlken.m17n.org> Original-Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18538 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18538 >> You said that the value associated with each key is always >> an integer, right? In that case, the value is always >> survive_gc_p, so it will never cause the key&value pair to >> be removed, > ??? See this code of sweep_weak_table (in fns.c). > for (idx = HASH_INDEX (h, bucket); !GC_NILP (idx); idx = next) > { > int i = XFASTINT (idx); > int key_known_to_survive_p = survives_gc_p (HASH_KEY (h, i)); > int value_known_to_survive_p = survives_gc_p (HASH_VALUE (h, i)); > int remove_p; > if (EQ (h->weak, Qkey)) > remove_p = !key_known_to_survive_p; > else if (EQ (h->weak, Qvalue)) > remove_p = !value_known_to_survive_p; > else if (EQ (h->weak, Qkey_or_value)) > remove_p = !(key_known_to_survive_p || value_known_to_survive_p); > else if (EQ (h->weak, Qkey_and_value)) > remove_p = !(key_known_to_survive_p && value_known_to_survive_p); > else > abort (); > If h->weak is Qkey, it sets remove_p only by checking > key_known_to_survive_p. So, it seems that wether the value > survives GC or not doesn't matter in this case. Yes, we agree 100%. If you passed Qt instead of Qkey, then the entries are removed if either key or value does not survive, but since your values are integers, they'll always survive. Stefan