From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Changes in GC and in pure space Date: Mon, 22 Jul 2019 18:43:45 -0700 Organization: UCLA Computer Science Department Message-ID: <8131cbef-3d58-1513-1fcc-5631d70211d0@cs.ucla.edu> References: <20190721193221.1964.53182@vcs0.savannah.gnu.org> <20190721193222.8C19E20BE2@vcs0.savannah.gnu.org> <83blxmqfkq.fsf@gnu.org> <83zhl6ortf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------531C7E31E8D17B68F38DA0F2" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="147506"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cc: pipcet@gmail.com, emacs-devel@gnu.org To: Stefan Monnier , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 23 03:43:57 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hpjqO-000cDx-Em for ged-emacs-devel@m.gmane.org; Tue, 23 Jul 2019 03:43:56 +0200 Original-Received: from localhost ([::1]:38530 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hpjqM-000849-Vr for ged-emacs-devel@m.gmane.org; Mon, 22 Jul 2019 21:43:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42171) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hpjqJ-00082c-EH for emacs-devel@gnu.org; Mon, 22 Jul 2019 21:43:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hpjqI-0007l8-9a for emacs-devel@gnu.org; Mon, 22 Jul 2019 21:43:51 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:46044) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hpjqG-0007h2-Kz; Mon, 22 Jul 2019 21:43:48 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5CDA2161672; Mon, 22 Jul 2019 18:43:47 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1lstZnDSuWqg; Mon, 22 Jul 2019 18:43:46 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 72C0D1616C2; Mon, 22 Jul 2019 18:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NRMUtM3un0at; Mon, 22 Jul 2019 18:43:46 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 39608161672; Mon, 22 Jul 2019 18:43:46 -0700 (PDT) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:238818 Archived-At: This is a multi-part message in MIME format. --------------531C7E31E8D17B68F38DA0F2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Stefan Monnier wrote: >>> As it happens, the issue with hash tables is bound up with the unexec thingy, in >>> that portable dumping currently can screw up hash tables with user-defined >>> tests. > > Note that AFAIK we currently don't dump any such hash-tables, so if > there's a bug there it only affects the case of the user *re*dumping > with a special config, which AFAIK we do not intend to officially > support yet for 27.1. Although I vaguely recall an email conversation to that effect, I don't see it in the Emacs documentation. And since unexec is now disabled by default, if people want to use any dumping method at all then by default they'll be redumping in the way that you suggest. If we really intend to not support that, we should be clearer about it in NEWS and documentation. At any rate the simplest workaround is to avoid pdumping the problematic hash tables, and I installed the attached patch to do that. We can add support for pdumping those hash tables later, if anybody cares about it. --------------531C7E31E8D17B68F38DA0F2 Content-Type: text/x-patch; name="0001-Do-not-pdump-user-defined-hashtabs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Do-not-pdump-user-defined-hashtabs.patch" >From 3f4a9a5a3b267fbc13a8bebc4295bbfadd6ff03e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 22 Jul 2019 18:33:39 -0700 Subject: [PATCH] Do not pdump user-defined hashtabs * src/pdumper.c (dump_hash_table_stable_p): Signal an error if a hash table has user-defined tests (Bug#36769). * src/fns.c (hashfn_user_defined): Now extern. --- src/fns.c | 2 +- src/lisp.h | 1 + src/pdumper.c | 2 ++ 3 files changed, 4 insertions(+), 1 deletion(-) diff --git a/src/fns.c b/src/fns.c index 8eefa7c72b..734a2e253c 100644 --- a/src/fns.c +++ b/src/fns.c @@ -4017,7 +4017,7 @@ hashfn_eql (Lisp_Object key, struct Lisp_Hash_Table *h) /* Given HT, return a hash code for KEY which uses a user-defined function to compare keys. */ -static Lisp_Object +Lisp_Object hashfn_user_defined (Lisp_Object key, struct Lisp_Hash_Table *h) { Lisp_Object args[] = { h->test.user_hash_function, key }; diff --git a/src/lisp.h b/src/lisp.h index 9d37629bc4..e96fcfe94d 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3606,6 +3606,7 @@ EMACS_UINT hash_string (char const *, ptrdiff_t); EMACS_UINT sxhash (Lisp_Object, int); Lisp_Object hashfn_eql (Lisp_Object, struct Lisp_Hash_Table *); Lisp_Object hashfn_equal (Lisp_Object, struct Lisp_Hash_Table *); +Lisp_Object hashfn_user_defined (Lisp_Object, struct Lisp_Hash_Table *); Lisp_Object make_hash_table (struct hash_table_test, EMACS_INT, float, float, Lisp_Object, bool); ptrdiff_t hash_lookup (struct Lisp_Hash_Table *, Lisp_Object, Lisp_Object *); diff --git a/src/pdumper.c b/src/pdumper.c index 2abac80a37..cda8b40be4 100644 --- a/src/pdumper.c +++ b/src/pdumper.c @@ -2628,6 +2628,8 @@ dump_vectorlike_generic (struct dump_context *ctx, static bool dump_hash_table_stable_p (const struct Lisp_Hash_Table *hash) { + if (hash->test.hashfn == hashfn_user_defined) + error ("cannot dump hash tables with user-defined tests"); /* Bug#36769 */ bool is_eql = hash->test.hashfn == hashfn_eql; bool is_equal = hash->test.hashfn == hashfn_equal; ptrdiff_t size = HASH_TABLE_SIZE (hash); -- 2.17.1 --------------531C7E31E8D17B68F38DA0F2--