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

so...I have no idea, but maybe for two consequently allocated objects, the instVar freeStart can remain with the same value ?



On Mon, Aug 1, 2011 at 8:43 AM, Igor Stasenko <siguctua@gmail.com> 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.




--
Mariano
http://marianopeck.wordpress.com