[Vm-dev] Re: [squeak-dev] identityHash bits not incremented for new objects?

[Nicolas Cellier]

Well distributed ?
In examples like Igor's one you'll likely get consecutive hashes...

Nicolas

2011/8/1 David T. Lewis <lewis at mail.msen.com>:
>
> On Mon, Aug 01, 2011 at 10:03:04AM +0200, Igor Stasenko wrote:
>>
>> On 1 August 2011 09:47, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
>> >
>> > Hi Igor. Does the same test work correctlly in a interpreter VM??? because I can see:
>> >
>> > ObjectMemory >> newObjectHash
>> > ?????? "Answer a new 16-bit pseudo-random number for use as an identity hash."
>> >
>> > ?????? lastHash := 13849 + (27181 * lastHash) bitAnd: 65535.
>> > ?????? ^ lastHash
>> >
>> >
>> > In which case, it seems that every new hash will be different than the previous one.
>> >
>> > But NewObjectMemory >> newObjectHash
>> > ?????? "Derive the new object hash from the allocation pointer.?? This is less costly than
>> > ?????? ??using lastHash because it avoids the read-modify-write cycle to update lastHash.
>> > ?????? ??Since the size of eden is a power of two and larger than the hash range this provides
>> > ?????? ??a well-distributed and fairly random set of values."
>> > ?????? <inline: true>
>> > ?????? ^freeStart >> BytesPerWord
>>
>> aha.. so this is the reason why hash is not incrementing!
>> Since BytesPerWord == 4
>> it means that hash will change only if old freeStart - new freeStart value >= 16
>>
>> and since two short strings 'ab' fit in 16 bytes, they receive same hash value.
>>
>> So, instead it should be:
>>
>>     ^freeStart // BytesPerWord
>>
>> since freeStart is aligned on BytesPerWord, but not (2^BytesPerWord)
>>
>
> Nice catch Igor!
>
> I think the intented implementation was probably this:
>
>        ^freeStart >> ShiftForWord
>
> Nasty sort of bug, it's the sort of typo that looks fine until you
> stop to think about it ;)
>
> Dave
>
>