[Pharo-project] identityHash bits not incremented for new objects?

Igor Stasenko siguctua at gmail.com
Tue Aug 2 09:49:27 EDT 2011


On 2 August 2011 15:31, Henrik Johansen <henrik.s.johansen at veloxit.no> wrote:
>
> On Aug 2, 2011, at 3:14 15PM, Igor Stasenko wrote:
>
>> On 2 August 2011 14:18, Henrik Johansen <henrik.s.johansen at veloxit.no> wrote:
>>>
>>> On Aug 1, 2011, at 8:43 53AM, Igor Stasenko wrote:
>>>
>>>> I found that #testBecomeIdentityHash sometimes failing, sometimes not.
>>>>
>>>> It seems like VM 'forgets' to produce different identityHash bits for
>>>> two consequently allocated objects,
>>>> while test assumes that they are always different.
>>>>
>>>> If i insert a statement (see the code), test no longer fails.
>>>>
>>>> testBecomeIdentityHash
>>>>       "Note. The identity hash of both objects seems to change after the become:"
>>>>
>>>>       | a b c d |
>>>>
>>>>       a := 'ab' copy.
>>>>       b := 'cd' copy.
>>>>
>>>>>>>    [ b identityHash = a identityHash ] whileTrue: [ b := b copy ].
>>>>
>>>>       c := a.
>>>>       d := b.
>>>>
>>>>       a become: b.
>>>>
>>>>       self
>>>>               assert: a identityHash = c identityHash;
>>>>               assert: b identityHash = d identityHash;
>>>>               deny: a identityHash = b identityHash.
>>>>
>>>> A simple piece of code reveals the problem:
>>>>
>>>> (1 to: 20) collect: [:i |
>>>>       'ab' copy basicIdentityHash ] #(954 954 955 955 956 956 957 957 958
>>>> 958 959 959 960 960 961 961 962 962 963 963)
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>
>>> What is the point of this test in the first place?
>>> To me it seems to test whether a VM's implementation of become: adheres to some properties.
>>> At least, VM bugs in traversal of references during become is the only way I could see the two first asserts EVER being false.
>>>
>>> As for the last assert (well, deny actually), in the context of what it's supposed to test as established above, it seems to me to say a VM should never give the same identityHash to subsequently copied objects. Which means
>>> a) It has nothing to do with become and identityHash, thus is in the test.
>>> b) Is this a property any code actually rely on?
>>>
>>> If not, why would we assert such a restriction on the VM implementation, or is it harmless?
>>>
>>> Either way, modifying the test to iterate till they ARE different, would make it meaningless in either case (and possible infinite loop in case of a really bad VM).
>>>
>>
>> There is strong reason to test identityHashes, because VM should
>> preserve an identity hash for oops.
>>
>> But of course test is wrong , because to test that , it should be like
>> following:
>>
>>     | a b hash1 hash2 |
>>
>>       a := 'ab' copy.
>>       b := 'cd' copy.
>>   hash1 := a identityHash.
>>   hash2 := b identityHash.
>>
>>   a become: b.
>>
>>       self
>>        assert: a identityHash = hash1;
>>        assert: b identityHash = hash2.
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
> Please include a comment with that. :)
> Like this has shown, it's rather hard to know wtf to do when you can't unambiguously read what its actually intended to test from the code itself.
>

The intent for preserving a hash is to not break hashed collections
which using identityhash:

a := 'aver' copy.

dict := IdentityDictionary new.
dict at: a put: 10.

a become: 'ijoewfj' copy.

self assert: (dict at: a) = 10

> Cheers,
> Henry
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-dev mailing list