[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69864: 30.0.50; Problem with equal hash tables
From: |
Stefan Monnier |
Subject: |
bug#69864: 30.0.50; Problem with equal hash tables |
Date: |
Sun, 17 Mar 2024 16:38:19 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Gerd Möllmann [2024-03-17 19:56:24] wrote:
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> (unsigned char *) data = 0x00007fb1f8a41978
>> "cl--generic-build-combined-method"
> Or, and maybe more plausible, someone modifies the hash-table keys used
> in the function above...
Lessee...
(defun cl--generic-build-combined-method (generic methods)
(let ((f
(with-memoization
;; FIXME: Since the fields of `generic' are modified, this
;; hash-table won't work right, because the hashes will change!
;; It's not terribly serious, but reduces the effectiveness of
;; the table.
(gethash (cons generic methods)
cl--generic-combined-method-memoization)
[...]
I suspect The Right Way would involve flushing the elements of the cache
when the generic is modified, or otherwise changing the hash-table index
so it doesn't include `generic` at all, or only the part that does
matter (as the code points out later on, currently this arg is not used
for much).
FWIW, I've never really measured the effectiveness of this cache.
It'd be worthwhile to do it at some point, because there's a good chance
its hit rater is very low (e.g. because its `:weakness` makes it lose
its info before we need it).
Stefan