Re: MPS: weak hash tables

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Pip Cet <pipcet@protonmail.com> writes:

> the strong part contains the hash values, next table, and index table,
> and the weak part contains both the keys and the values, in a single
> array of length 2 * size. 

See, I overlooked that! Then I think we're good :-). Thanks for
explaining this.

> Rather than adjusting the stride and keeping things in a single cache
> line in this (slow, anyway) case, we store all keys in
> weak->entries[0..table_size], and all values in
> weak->entries[table_size..2*table_size]. * when MPS splats a key, we
> (not MPS) splat the value before it is scanned * when MPS splats a
> value, we splat the key after it has been scanned * it appears to
> work:
>
> (setq table (make-hash-table :weakness 'key-and-value))
>
> (puthash t (cons 1 2) table)
> (puthash (cons 3 4) t table)
> (puthash (cons 5 6) (cons 7 8) table)
>
> (hash-table-count table) ;; => 3
>
> (igc--collect)
>
> (hash-table-count table) ;; => 1
>
> (setq values nil)
>
> (igc--collect)
>
> (hash-table-count table) ;; => 0
>
>
> What confused me was the "after it has been scanned" part. I believe
> that means we keep the objects alive until we scan again, but as
> splatting isn't perfectly eager anyway, that should rarely become a
> problem.

Agree.

>> Hm, maybe they are value weak? Key-weak would make no sense, I think,
>> indeed.
>
> emacs-lisp/macroexp.el:(defvar macroexp--warned (make-hash-table :test #'equal :weakness 'key))
> emacs-lisp/map-ynp.el:(defconst read-answer-map--memoize (make-hash-table :weakness 'key :test 'equal))
> emacs-lisp/pcase.el:;; (defconst pcase--memoize-2 (make-hash-table :weakness 'key :test 'equal))
> org/org-macs.el:(defvar org-sxhash-hashes (make-hash-table :weakness 'key :test 'equal))
>
> are key-weak...

Hm. What haopens is that some specific key K is stored in the hash table.
Lookup can use any key equal to K, but the splat happens only if K is no
longer referenced. Example maybe, K is stored in some object O, and we
want to lookup something related to K without always having access to O,
but we want the table to also tell us when O is no longer in use.
Something like that?

>> From my POV, it's not a deal breaker if 32-bit systems don't work with
>> igc, They still have the old GC, and 32-bit systems are kind of obsolete
>> even Intel says and so on. It would be nice if we could that working of
>> course.
>
> My concern is that Ravenbrook may get around to implementing emulation
> for aarch64 or amd64.

They are not very active anymore, and we could raise concerns and ask
them to make that opt-in :-).

>> 
>> Yeah, that's another point I forgot about. The trickery MPS does on
>> Windows and Linux with 32-bits. The consequences of which are another
>> very good reason to declare 32-bit systems as not supproted, from my
>> POV.
>
> Oh, that's on Windows, too? I believe that might mean Eli might run
> into weird bugs...

I think they said somewhere it was done on Win32, but I can't find it at
the moment.

> Thanks again, and thanks for the asserts.

Thanks to you for your work!