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

[David T. Lewis]

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