From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Make purecopy create hash tables properly Date: Sat, 28 Jan 2017 09:58:55 -0500 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1485615562 18900 195.159.176.226 (28 Jan 2017 14:59:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 28 Jan 2017 14:59:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: "emacs-devel@gnu.org" To: Vibhav Pant Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 28 15:59:18 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cXUSz-0002uz-Mk for ged-emacs-devel@m.gmane.org; Sat, 28 Jan 2017 15:59:01 +0100 Original-Received: from localhost ([::1]:52142 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cXUT5-00030y-38 for ged-emacs-devel@m.gmane.org; Sat, 28 Jan 2017 09:59:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58359) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cXUSx-0002yx-PR for emacs-devel@gnu.org; Sat, 28 Jan 2017 09:59:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cXUSu-0002HM-Qi for emacs-devel@gnu.org; Sat, 28 Jan 2017 09:58:59 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:6365) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cXUSu-0002G4-K6 for emacs-devel@gnu.org; Sat, 28 Jan 2017 09:58:56 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A7FAAu3EVY/0gvq8BdGwEBAQMBAQEJAQEBgzgBAQEBAR+EW4VUhHiXCiYBkkeCD4IIhhwEAgKCEUAUAQIBAQEBAQEBYiiEaQEEAScvIwULCzQSFBgNJIh6CKxXPYtEAQEBBwIlixmKKQWPfIpqkwmIETGGCZIPHzd4Ew6DWx2BeyCJLQEBAQ X-IPAS-Result: A0A7FAAu3EVY/0gvq8BdGwEBAQMBAQEJAQEBgzgBAQEBAR+EW4VUhHiXCiYBkkeCD4IIhhwEAgKCEUAUAQIBAQEBAQEBYiiEaQEEAScvIwULCzQSFBgNJIh6CKxXPYtEAQEBBwIlixmKKQWPfIpqkwmIETGGCZIPHzd4Ew6DWx2BeyCJLQEBAQ X-IronPort-AV: E=Sophos;i="5.33,749,1477972800"; d="scan'208";a="290643420" Original-Received: from 192-171-47-72.cpe.pppoe.ca (HELO pastel.home) ([192.171.47.72]) by smtp.teksavvy.com with ESMTP; 28 Jan 2017 09:58:55 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 3086164EAB; Sat, 28 Jan 2017 09:58:55 -0500 (EST) In-Reply-To: (Vibhav Pant's message of "Sat, 28 Jan 2017 15:55:08 +0530") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:211696 Archived-At: > Not sure if I'm correct here, but shouldn't we be *not* purecopying weak hash > tables? Good point. So we should check NILP (old->weak) and signal an error if set. And thus old->next_weak should always be NULL and is trivial to copy. > I'd recommend skipping purecopy for hash tables altogether, and add an That would imply we can't purecopy any object which ends up referencing a hash-table. Unless we arrange to keep track of those hash-tables which are referenced from purespace. We already do that for symbols, so maybe we can extend/generalize that mechanism (probably a good idea). > internal :read-only flag to (make-hash-table) for hash tables we know > aren't going to be be written to, and are thus safe to be purecopied > (this would obviously only be useful for hash tables that are defined > using printed syntax). For cons cells we do: CHECK_IMPURE (cell, XCONS (cell)); in `setcar', so we can do the same for hash-tables. Since purespace is contiguous, CHECK_IMPURE is pretty efficient, and since it only relies on the pointer value, the CPU can compute it in parallel with the access to the object (and the test itself is trivial to predict), so it should have a negligible impact on performance. Stefan