Not sure if this small point was ever addressed:-

Scott A Crosby wrote:


> Thus, the added layer of 'longHash' seems ill-defined and pointless. If an
> object needs more hash bits, can it not store those bits as an internal
> field, and override 'hash' with a new function returning those bits?
Not in the sense of keeping a larger hash in the object header, no.
There is a limit on the space available and 12 bits is it.

Now, we could extend the object format to address this; I seem to
remember that at least one Smalltalk (Tek?) allowed for an extra word to
be added to the object to hold a 32bit hash if needed. However, it is
pretty rarely needed and so I'm not sure the complication would be worth
it. In Squeak one could conceivably add an optional fourth header word
to allow a similar capability, but that would also add complications.
The annoying part of any of these possibilties is that the hash value is
not often needed and so it hurts to pay the price.

In some cases, with luck the most common ones, we might be able to
implement a fast linear search prim to help. Clearly it would be limited
to searching for only object identity matches (unless one wanted to get
really clever with sending #= from a primitive loop - all sorts of fun
problems with that) but might be good enough.

tim