harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Performance improvement of java.util.HashMap
Date Fri, 29 Jun 2007 14:27:22 GMT
Jimmy,Jing Lv wrote:
> 2007/6/29, Sergey Kuksenko <sergey.kuksenko@gmail.com>:
>> The first solution has one advantage - it can be done only in 
>> classlib. The second variant should be implemented in all VMs which
>> are based on Harmony's classlib. But this way has other advantages
>> - Well-formed IdentityHashCode will helps not only for HashMap, but
>> for Hashtable, IdentityHashMap and moreover for all hashing
>> implemented by users.
> Ah, I never think of it, so you mean IdentityHashCode can be
> implemented in vm?

It always will be in Harmony, since it is obtained by
System#identityHashCode(Object), which is in the kernel class set.

> Doesn't vm return directly the address as the
> IdentityHashCode?(it is easiest and fastest way)

It is typical for the implementation to return the object address at the
point was first asked for it's identityHashCode, but that is not
required by the spec.

>> In the second variant we don't add rehashing function into HashMap. It is
>> common practice when advanced Java developers tune their HashCode
>> functions.
>> If we add rehashing function into HashMap we may break their tuning,
>> without
>> knowledge of internal rehashing functions it is impossible to tune
>> HashCode
>> function.
>> From my opinion we should think about the last argument against adding
>> rehashing into HashMap and move rehashing into VM.
> Yes, the improved identityHashCode may help, but usually users also
> define their own hashcode, then the identityHashCode may not help,
> while rehash in classlib still works, that's why I guess improvement
> in classlib is better :)

Since the developer is defining the hashCode() I don't see how you would
know the best way to improve their value?  I think we just rely on them
to do their job properly or suffer the consequences :-)


View raw message