GNU bug report logs - #25743
rehash-size ignored

Previous Next

Full log

Message #13 received at 25743-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 25743-done <at> debbugs.gnu.org
Subject: Re: bug#25743: rehash-size ignored
Date: Fri, 26 Jul 2019 13:16:10 -0400

>     * src/fns.c (maybe_resize_hash_table): Completely initialize the
>     new ‘next’ vector before allocating more vectors, as this
>     preserves locality a bit better and it’s 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?

This patch fixes the most severe problem (which was that the table was
larger than requested and we didn't take it into account in the rest of
the code).

But it doesn't fix the problem in the title: by default rehash-size is
1.5 yet in practice the code just doubles the size (because
larger_vecalloc only allocates something smaller than twice the
original size when we're reaching the maximum possible size).

So I installed the patch below to finish it.
Thanks,


        Stefan


diff --git a/src/fns.c b/src/fns.c
index f4f3b95ac6..c45f455646 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -4190,7 +4190,7 @@ maybe_resize_hash_table (struct Lisp_Hash_Table *h)
 	 avoid problems if memory is exhausted.  larger_vecalloc
 	 finishes computing the size of the replacement vectors.  */
       Lisp_Object next = larger_vecalloc (h->next, new_size - old_size,
-					  PTRDIFF_MAX / 2);
+					  new_size);
       ptrdiff_t next_size = ASIZE (next);
       for (ptrdiff_t i = old_size; i < next_size - 1; i++)
 	gc_aset (next, i, make_fixnum (i + 1));

Previous Next

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