[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25743: rehash-size ignored
From: |
Stefan Monnier |
Subject: |
bug#25743: rehash-size ignored |
Date: |
Fri, 26 Jul 2019 13:16:10 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
> * 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));