[Vm-dev] Questions about hash

[Eliot Miranda]

On Thu, Jan 6, 2011 at 6:23 AM, Mariano Martinez Peck <marianopeck at gmail.com
> wrote:

>
> Hi folks. I am trying to understand a little how hash is assigned and how
> it works in the SqueakVM. I have a couple of questions:
>
> 1) There are 12 bits in the ObjectHeader for the hash. I saw that the value
> of this hash comes from #newObjectHash. But....this method answers a hash of
> 16 bit:
> newObjectHash
>     "Answer a new 16-bit pseudo-random number for use as an identity hash."
>
>     lastHash := 13849 + (27181 * lastHash) bitAnd: 65535.
>     ^ lastHash
>
> Since in the OH we have 12 bits, each place where this method is used, then
> we have to do something like this:
>
> header1 := (classFormat bitAnd: 16r1FF00) bitOr: (hash << HashBitsOffset
> bitAnd: HashBits).
>
> or
>
>     hash := self newObjectHash.
>     header := (self longAt: newOop) bitAnd: 16r1FFFF.
>     "use old ccIndex, format, size, and header-type fields"
>     header := header bitOr: ((hash << 17) bitAnd: 16r1FFE0000).
>
> ....
> so, we always need to trim it to 12 bits using (hash << HashBitsOffset
> bitAnd: HashBits).
>
> Now, I wonder, why #newObjectHash  does not answer a 12bits long hash
> directly ?  is it because of the hash function performance?
>
>
> 2)  It looks to me that not, but can it change the hash of an object? if
> true, why and where?
>
> 3) If #basicIdentityHash is ONLY used for Sets and friends, why not letting
> the hash assignment as late/lazy as possible? i mean, instead of creating
> and assigning a hash at object creation, what if we do this in #hashBitsOf:
> oop
> where we can check in the hash is empty and if true assign one.
> Would this make sense or it would be worst?
>

IMO it is far better and I will implement this in the new object
representation.  VW has always had lazy hash creation.

Note in Cog the hash is derived from the allocation pointer not from the
pseudo-random hash generator, avoiding a read-modify-write cycle in object
allocation.

best
Eliot


> Thanks
>
> Mariano
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110106/f9da538d/attachment.htm