From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#25743: rehash-size ignored Date: Fri, 26 Jul 2019 15:55:07 +0200 Message-ID: <87tvb8lx38.fsf@mouse.gnus.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="174014"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 25743@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 26 15:56:07 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 1hr0hb-000j7r-KV for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Jul 2019 15:56:07 +0200 Original-Received: from localhost ([::1]:40148 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hr0ha-0004cT-Nq for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Jul 2019 09:56:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35614) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hr0hY-0004cM-5i for bug-gnu-emacs@gnu.org; Fri, 26 Jul 2019 09:56:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hr0hW-0002h2-Tx for bug-gnu-emacs@gnu.org; Fri, 26 Jul 2019 09:56:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34226) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hr0hW-0002gr-PZ for bug-gnu-emacs@gnu.org; Fri, 26 Jul 2019 09:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hr0hW-0001bt-IA for bug-gnu-emacs@gnu.org; Fri, 26 Jul 2019 09:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Jul 2019 13:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25743 X-GNU-PR-Package: emacs Original-Received: via spool by 25743-submit@debbugs.gnu.org id=B25743.15641493174709 (code B ref 25743); Fri, 26 Jul 2019 13:56:02 +0000 Original-Received: (at 25743) by debbugs.gnu.org; 26 Jul 2019 13:55:17 +0000 Original-Received: from localhost ([127.0.0.1]:41581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hr0gn-0001Dr-3Z for submit@debbugs.gnu.org; Fri, 26 Jul 2019 09:55:17 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:34198) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hr0gj-0001Ag-Dy for 25743@debbugs.gnu.org; Fri, 26 Jul 2019 09:55:14 -0400 Original-Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hr0ge-0006wD-AR; Fri, 26 Jul 2019 15:55:10 +0200 In-Reply-To: (Stefan Monnier's message of "Wed, 15 Feb 2017 14:18:54 -0500") 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:163782 Archived-At: Stefan Monnier writes: > Looking accidentally at maybe_resize_hash_table, I noticed that we don't > obey resize_hash, although we do all the work needed for that. > Worse, we make dangerous assumptions about the behavior of > larger_vector: > > maybe_resize_hash_table takes `old_size' from `ASIZE (h->next)' and then > uses rehash_size to compute the desired new_size. The problem comes > here: > > set_hash_key_and_value (h, larger_vector (h->key_and_value, > 2 * (new_size - old_size), -1)); > set_hash_next (h, larger_vector (h->next, new_size - old_size, -1)); > > This says, that h->next and h->key_and_value are replaced by new vectors > that are larger than the previous one so that they are large enough to > accomodate new_size. I did not follow the recent thread about hash table resizing closely, but I do seem to remember somebody saying that they'd fixed something in the hash resizing code, and the commits in fns.c seem to back that up: commit 49e80e765b693736a8bb97ae5bfa341d25bf4f02 Author: Paul Eggert Date: Sat Jul 20 23:21:14 2019 -0700 Tweak recent hash-table fix =20=20=20=20 * src/fns.c (maybe_resize_hash_table): Completely initialize the new =E2=80=98next=E2=80=99 vector before allocating more vectors, as th= is preserves locality a bit better and it=E2=80=99s safer not to leave an uninitialized Lisp object around. Use next_size instead of new_size to compute new index size. So is the issue discussed in this bug report fixed now? --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no