From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Daniel Colascione" Newsgroups: gmane.emacs.bugs Subject: bug#36447: 27.0.50; New "Unknown keyword" errors Date: Wed, 10 Jul 2019 10:16:41 -0700 Message-ID: <533a60e1856bcddd6a4f7eea5602549e.squirrel@dancol.org> References: <875zon7x0a.fsf@web.de> <87lfxdgs1k.fsf@web.de> <83y31capj1.fsf@gnu.org> <83tvc0anwi.fsf@gnu.org> <83r274an61.fsf@gnu.org> <83pnmoacft.fsf@gnu.org> <83bly7acg9.fsf@gnu.org> <83ef2y4nsm.fsf@gnu.org> <735465eebd8f96d3969d42e6f734f69e.squirrel@dancol.org> Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="180937"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: SquirrelMail/1.4.23 [SVN] Cc: michael_heerdegen@web.de, npostavs@gmail.com, Stefan Monnier , 36447@debbugs.gnu.org To: "Pip Cet" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 10 19:17:38 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1hlGDo-000koH-HC for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Jul 2019 19:17:37 +0200 Original-Received: from localhost ([::1]:35582 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlGDn-0001md-Gf for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Jul 2019 13:17:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46853) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlGDS-0001ke-RR for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2019 13:17:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hlGDK-00081N-IS for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2019 13:17:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55969) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hlGDG-0007zp-3X for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2019 13:17:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hlGDF-0001KA-Kn for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2019 13:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Daniel Colascione" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2019 17:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36447 X-GNU-PR-Package: emacs Original-Received: via spool by 36447-submit@debbugs.gnu.org id=B36447.15627790165075 (code B ref 36447); Wed, 10 Jul 2019 17:17:01 +0000 Original-Received: (at 36447) by debbugs.gnu.org; 10 Jul 2019 17:16:56 +0000 Original-Received: from localhost ([127.0.0.1]:36557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlGDA-0001Jm-DZ for submit@debbugs.gnu.org; Wed, 10 Jul 2019 13:16:56 -0400 Original-Received: from dancol.org ([96.126.100.184]:38764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlGD7-0001Jd-Hz for 36447@debbugs.gnu.org; Wed, 10 Jul 2019 13:16:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=UWeDf8ao0jx06h43A1MgoWZrAlzKvea9jBfOMspgF04=; b=OcbkQGlt4J3xDIp+Zhr9FL5gTVGEyKvWN0S17XdGaXelPss0NyyWRhZCBHSqKkI8PyCHRfWJeXr/XF7EYXTtumwkd3bhQ6BWAV/r4gxS1/xWDcd/N3n+6Jiz9ihI/dC7rJUFLUR2yQ9XVoOEosv7SBCEN20clriWR6ul30kdvPvyB9YHz9tYICAFlBhtccD7XW5KGFMw3cRRnvW0kcdVOkpS6RlpgtOmY8Owox2uv8pigDktDq8aL1Z6Dxx1E93BCCZLoaL/p5WsRU4axrNUxLezY8MHn0/VM7YLOpODckMaF+NV5M99p2BsxoKSBUWUIDzAVR1ZjN14t1tYUWgtlw==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlGCv-00020l-Sg; Wed, 10 Jul 2019 10:16:42 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Wed, 10 Jul 2019 10:16:41 -0700 In-Reply-To: X-Priority: 3 (Normal) Importance: Normal X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:162653 Archived-At: > On Wed, Jul 10, 2019 at 3:19 AM Daniel Colascione > wrote: >> #1 works, but it's somewhat inefficient. >> >> #2 is a variant of #1, in a sense. Instead of copying the hash table >> vectors and mutating them, we rebuild them from scratch. I don't >> understand why we have to do that eagerly. > > I'm sorry if I suggested that we must do that. On the contrary, both > options are entirely viable, though on balance I prefer the eager > version. > > The lazy approach makes the code more complicated, I don't think doing it eagerly is a complexity win. The eager patch posted upthread is a wash. > slightly slower, No it doesn't. The hash table branch on negative count should be predicted correctly and involves a test against a cache line we're loading anyway. We can add explicit likely() and unlikely() annotations too. > and introduced what appears to me to be at least one bug > (Fhash_table_count returns a negative integer if called with a > non-rehashed hastable). That's a trivial oversight and not an inherent difficulty in the lazy approach. > The eager approach slows down startup by a fraction of a millisecond > (it might be an entire millisecond if your Emacs session doesn't > access any of the dumped hash tables at all, but since it does tend to > do that, it'll be less in practice). A millisecond here and a millisecond there and things end up costing real time. A lazy approach isn't any harder than an eager one and >> #1 isn't as bad as you might think. > > But it's not as good as "do #1 but only if PURE_P", which no longer works. > >> It's the same work either way, except that if we copy, when we grow the >> hash table, we can actually free the original vectors. > > I'd like to restrict #1 to hash tables which are somehow immutable, > either because they're pure or because we actually introduce immutable > objects, so they'd never grow. Mutable hash tables must not share > their index vectors anyway. Did you miss the part about avoiding copy-on-write faults? Those hash table vectors are going to be copied anyway, and we might as well do it ourselves instead of making the kernel do it. (unexec has the same inefficiency, BTW.) We should just do #1 for all hash tables. >> IMHO, the right approach is to check in #1 for now and switch to a >> #2-like >> approach once master is stable. Noticing that we don't actually have to >> store the hash table internal arrays in the dump is a good catch. > > I agree, but I think we should discuss the future of pure space, too. > Maybe we should have a separate bug for that, though. Sure.