[squeak-dev] true hash
Chris Muller
asqueaker at gmail.com
Thu May 10 17:16:29 UTC 2012
>> I should add, it's already happened. In 2009 Levente changed
>> Object>>#identityHash to answer the scaledIdentityHash.
>
> Not in Squeak. Our IdentityDictionary uses scaledIdentityHash nowadays, but identityHash itself is left alone, answering the primitive value directly.
I meant to say Object>>#hash, not #identityHash.
So, before 12/1/2009:
true hash "2950"
but after 12/1/2009
true hash "773324800"
So, any saved persistent EToys ReferenceStream object-models files
with true involved in the calculation of #hash prior to 2009 will now
be goofed up unless you remember to rehash all regular Dictionary's
after loading it. The properties of this bug are:
- it is hidden, you had no idea it was there because no SUnit test
can possibly catch it. It didn't show until production.
- it is image-specific -- you load the file an image before
Levente's change and everything seems fine. What's going on?
- it is "intermittent" because there's a small possibility that, if
the Dictionary were small, you might get lucky with a "hit" anyway
when calculating the slot to start searching at
- it could lead to corrupt data model, because perhaps the app does
something like #at:ifAbsentPut:, and maybe even on an
otherwise-equivalent object, so you end up with TWO of the "same"
object in the dictionary. What a disaster!
Now does it make sense?
More information about the Squeak-dev
mailing list
|