[Vm-dev] Re: [squeak-dev] identityHash bits not incremented for
David T. Lewis
lewis at mail.msen.com
Mon Aug 1 11:11:47 UTC 2011
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 ;)
More information about the Vm-dev