GNU bug report logs - #36447
27.0.50; New "Unknown keyword" errors

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Daniel Colascione <dancol <at> dancol.org>
Cc: michael_heerdegen <at> web.de, npostavs <at> gmail.com, pipcet <at> gmail.com, 36447 <at> debbugs.gnu.org
Subject: bug#36447: 27.0.50; New "Unknown keyword" errors
Date: Wed, 10 Jul 2019 05:38:01 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  michael_heerdegen <at> web.de,  npostavs <at> gmail.com,  36447 <at> debbugs.gnu.org
> Date: Tue, 09 Jul 2019 17:05:53 -0400
> 
> I think we should get Daniel's opinion on this.

Daniel, could you please comment on the issues discussed in this bug?

> > On Sat, Jul 6, 2019 at 6:45 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> > > Indeed. I'm attaching a proof of concept that we can simply freeze the
> >> > > hash tables when dumping and thaw them when loading a dump, which
> >> > > includes rehashing. Do you happen to know why it wasn't done that way?
> >> >
> >> > I'd guess it was to shorten the startup time by doing this rehashing lazily.
> >>
> >> The function pdumper-stats with show the time it took to load Emacs,
> >> so the effect of this on the load time can be measured
> >
> > I'm measuring it directly, and it's more than I expected: about a
> > millisecond, for 4,300 hash table entries. What we can't easily
> > measure is how much the lazy rehashing code would slow us down anyway.
> >
> > For comparison, the entire time stored in pdumper-stats is 15 ms here.
> >
> > I don't think that's significant, because we'd probably end up
> > rehashing most of the large hash tables anyway. We're saving some 250
> > KB of space in the pdmp image, which was previously used for redundant
> > information. (I'm surprised it's that much, but I guess pdumper
> > relocations are fairly large?)
> >
> > I'm attaching a revised patch, which uses vectors rather than consed
> > lists for both the key_and_value vector, avoiding a copy in the common
> > case where there is more than one hash table entry, and for the list
> > of hash tables. It still contains debugging/timing code.
> >
> > charset.c currently assumes hash table entries will stay at the same
> > index in Vcharset_hash_table. I think that works okay in practice,
> > because we don't shrink or reorder hash tables, but it was still a bit
> > of a nasty surprise.
> >
> > This concept appears to work: modify pdumper to special-case hash
> > tables and freeze/thaw them properly. You probably shouldn't dump hash
> > tables with complicated user-defined hash functions.
> >
> > Both PURE_P and pdumper_object_p fail to distinguish between tables
> > that were pure or impure before being dumped.
> >
> > This also fixes the bug that (hash-table-count dumped-hash-table) will
> > return a negative number if no previous access to the hash table has
> > happened, but of course we can fix that directly...
> >
> > Of course, we're still modifying purecopied information.
> 
> 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.