[Glass] Why #identityHash does not rely on OOP?

[Paul Baumann via Glass]

Gs doesn't have the problems common in 32-bit versions of other dialects
related to collisions from short #identityHash range. I recall the 32-bit
version of VisualWorks answered a 16k value range and that caused huge
performance problems for large identity hashed collections. A 4k range must
have been a nightmare. Even 32-bit versions of Gs do well with extremely
large collections.

Paul Baumann

On Oct 26, 2016 10:51 AM, "Mariano Martinez Peck via Glass" <
glass at lists.gemtalksystems.com> wrote:

> I am sure the answer is dumb, but I still wonder. At a first glance I
> thought it could be because you may reuse OOPs. But...if you re-use a OOP
> is because that object is not anywhere in the system (and hence, there is
> no need of re-hash any collection).
>
> Another thought I had is none-persisting object and the costs of getting
> available OOPs vs a simply #identityHash implementation.
>
> BTW how long is the #identityHash? In Pharo (before Spur) we had 12 bits
> (or similar) in the object header so that yield 4k different values. That's
> not fun when you have large identity-based hashed collection because of
> collisions.  Anyway, how big is the identity hash in Gemstone? Or how
> "unique" it is?
>
> Anyway, I was simply curious about this topic and would like you know your
> thoughts.
>
> Best,
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20161026/d905e9b1/attachment-0001.html>