[Soot-list] bug with makeAllocNode?

[lpxz]

Hello Pat:
    yes, JNewExpr is using java equals() implementation. which is object 
equality.
By default (in Object.java), equals() is simply implemented using ==, 
which only returns true when two objects
have the same memory address.

    Now, in hashmap.java, the refinement condition is:  if (e.hash == 
hash && ((k = e.key) == key || key.equals(k))), as equals() is not 
overriden, the condition can be simplified to be:
if (e.hash == hash && (e.key == key ))

*Trace:
expr:new java.io.DataInputStream hashcode:145892892 
----find--->allocNode AllocNode 2445 new java.lang.StringBuilder in 
method <sun.security.jca.ProviderList: void <init>()> hashcode:2445*
*
which keys really correspond to AllocNode2445 in the hashmap?  ::::::new 
java.lang.StringBuilder145892892*

    But based on this trace, JNewExpr "new *java.io.DataInputStream* 
*hashcode:145892892*" and "*new java.lang.StringBuilder145892892* " have 
the same hashCode(), I can not understand this point, because I think 
their hashCode() is assigned based on the memory address. But this 
really happens, two objects are having the same hashCode, so 
"e.hash==hash" returns true.
What is more, "e.key==key" returns true too, which is reflected from the 
execution trace.I can not understand this point too, because I think 
that expression would return true iff e.key and key are having the same 
memory address.

I do not know the underlying implementation of  hashCode(), equals(), == 
(I am using jrockit), but from the above  case,  I would prefer to use 
specified hashCode(), equals() instread of the default version from the 
jrockit. Because the specified hashCode() (equivHashCode()) is a hashing 
on the refType,  This specified hashCode() can avoid  the false hit 
through the filtering condition: "e.hash==hash" in advance,  instead of 
postponing the type checking after we have already got a retNode.

    Do you think  using a specified hashCode()  to be a reliable 
candidate implementation?


**


Regards
Peng


**

> Patrick Lam wrote:
>   
>> I looked at the implementation of equals() in JNewExpr, and that should
>> never happen. Actually, JNewExpr delegates to AbstractNewExpr.equivTo,
>> which is:
>>
>>     public boolean equivTo(Object o)
>>     {
>>         if (o instanceof AbstractNewExpr)
>>         {
>>             AbstractNewExpr ae = (AbstractNewExpr)o;
>>             return type.equals(ae.type);
>>         }
>>         return false;
>>     }
>>
>> so it should only return true for new statements with the same type,
>> unless there's a bug in the equals() method for type.
>>     
>
> Let me just clarify that JNewExpr has no equals() implementation, so it
> uses the default Java equals() implementation, which is object equality.
> JNewExpr also inherits equivTo() from AbstractNewExpr. equivTo() should
> not be relevant for maps.
>
> pat
>
>   

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