[infinispan-dev] Equivalence vs. MurmurHash3

[Sanne Grinovero]

+1

See also https://issues.jboss.org/browse/ISPN-3905 ; although I was
mostly concerned on it allocating on a (very) hot path and didn't look
at it in terms of compatibility modes.

Rather than xorring with "magic numbers" don't you think we
Equivalence implementation should be able to rule on that?

On 23 November 2015 at 10:26, Radim Vansa <rvansa at redhat.com> wrote:
> Hi guys,
>
> I have noticed that even in library mode we use MurmurHash3 to find out
> the segment for particular key. For strings, this involves encoding into
> UTF-8 and computation of hashCode, instead of just reading the cached
> value in string. Common objects just remix the bits of hashCode. When
> user provides custom Equivalence with non-default hashCode, it is not
> used to determine the segment.
>
> I think that in library mode we should rather use Equivalence.hashCode,
> maybe XORed with some magic number so that there are less collisions in
> DataContainer.
>
> If we simply replaced the function in CH, we would break the case when
> user starts HR server on top of library mode, as the clients expect key
> location based on MurmurHash3. ATM user only has to set
> AnyServerEquivalence for keys in DC; we would need to detect
> configuration with server equivalence and set CH function to MH3, and
> probably also log some warning if the equivalence is set to unknown
> class and CH function is not specified.
>
> WDYT?
>
> Radim
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev