[Soot-list] bug with makeAllocNode?

[lpxz]

Hello pat:
    Yes, I agree with you. the implementation of hashmap is through  
table[indexFor(hash, table.length)].
    and be refined through:  if (e.hash == hash && ((k = e.key) == key 
|| key.equals(k)))

   But here, for newExpr, we only cares about the reftype, right?
   perviously in the hashmap, we have "new A()"-> AllocNode1
   while later we have "new B()", we do not want to retrieve out 
AllocNode1. we want it return a null, and create a new AllocNode2.
    But here, "new B()" have the same hashcode as "new  A()" , so they 
retrieve out the AllocNode1.
    and the following check would through runtimeException.I can not 
quite explain here why two objects have the same native hashCode(). but 
in my run, it would happen frequently, If I do not add 
-Xbootclasspath/p:hack.jar
There would be no such problems. I can not explain this because the 
Xbootclasspath seems have nothing to do with native hashCode().

    Instread, we can make sure "new B()" does not have the same hashcode 
as "new A()", we can achive this by hashing on the reftype's classname. 
Then the exception is not thrown any more, "new B" would not retrieve 
allocNode1 actually.


Regards
Peng
Patrick Lam wrote:
> lpxz wrote:
>   
>> we can see that two JNewExpr objects have the same hashcode although
>> they are of different types.
>>     
>
> Hi Peng,
>
> It seems that you're assuming that two objects with the same hashCode
> are equal. That's not the guarantee from hashCode. hashCode guarantees
> that objects with different hashCodes are different. That's why you
> typically have to use chaining when you implement a hash table, and also
> why it is acceptable for a hashCode implementation to always return 0.
>
> Let me know if I misread your mail.
>
> pat
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20091208/749741b0/attachment.html