[Openmcl-devel] rehash hashtree when using EQ test functions

Taoufik Dachraoui dachraoui.taoufik at gmail.com
Fri Jun 19 12:45:19 PDT 2015


I designed a procedure to determine when to rehash the hashtree when
using EQ or EQL test functions, and would like to know if it is correct;

The idea is simple, I use a parameter *rehash-test*, and on each
make-htree I compute its hash code using EQHASH (or EQLHASH)
and I save the gc-count and then use the following code to determine
if rehashing is necessary (the code is more clear than my english):

(defparameter *rehash-test* (cons nil nil))

(defun %rehash (htree)
  (if (and (not (%ht-rehashing htree)) ; not already rehashing the htree
           (> (ccl::%get-gc-count) (%ht-gc-count htree)) ; compare gc-count
to the saved one
           (not (= (%ht-rehash-test htree) ; if hash code of *rehash-test*
is changed
                   (setf (%ht-rehash-test htree)
                         (if (eq (%ht-test htree) 'eq)
                             (eqhash *rehash-test*)
                             (eqlhash *rehash-test*))))))
        (setf (%ht-rehashing htree) t) ; make sure not to re-enter the
        (htrehash htree)
        (setf (%ht-rehashing htree) nil))))

My assomption was, that when there is a full GC, if the *rehash-test* hash
is changed this means that the cons was moved around and this means that
or at least some keys in htree are moved arround (address change)

Is my assomption correct? (the tests till now are correct but I still have

Kind regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20150619/e3c2435e/attachment.htm>

More information about the Openmcl-devel mailing list