[15] RFR (xs) 8046362 IdentityHashMap.hash comments should be clarified

Martin Buchholz martinrb at google.com
Fri Feb 7 17:10:53 UTC 2020


I explored System.identityHashCode (see below).
They appear to be high quality, pre-mixed ints (not just addresses).
I suggest that IdentityHashMap simply trust System.identityHashCode.
I'm surprised at any attempt to defend against high bits being zero.  I'm
far more worried about low bits, as would happen if identityHashCode just
returned the bottom 32 bits of an address, perhaps shifted insufficiently.
But this is 2020.  Trust the VM!  If the VM is broken, fix it!
---
import java.lang.reflect.Constructor;

public class IdentityHashCodes {
    static class F1 { int x; }
    static class F2 { int x; int y; }

    static void printHashCodes(Class<?> clazz) throws Throwable {
        System.out.printf("--- %s ---%n", clazz.getSimpleName());
        Constructor<?> c = clazz.getDeclaredConstructor();
        for (int i = 30; i--> 0; )
            System.out.printf("%x%n",
System.identityHashCode(c.newInstance()));
    }

    public static void main(String[] args) throws Throwable {
        printHashCodes(Object.class);
        printHashCodes(F1.class);
        printHashCodes(F2.class);
    }
}

On Fri, Feb 7, 2020 at 6:03 AM Doug Lea <dl at cs.oswego.edu> wrote:

>
> > I don't get what hash() is doing with the low bits. Maybe we want
> > something like mix32.
>
> It is mainly spreading them upwards because some (varying over time) top
> bits of identityHashCode are always 0.
>
> -Doug
>
>
> >
> > On Thu, Feb 6, 2020 at 1:01 AM Andrew Haley <aph at redhat.com
> > <mailto:aph at redhat.com>> wrote:
> >
> >     On 1/28/20 11:41 PM, Stuart Marks wrote:
> >
> >     > As an aside, I don't know whether the linear-probing (open
> >     > addressed) arrangement of IdentityHashMap is in fact faster than
> the
> >     > separate chaining approach of HashMap. Perhaps investigating that
> >     > could be a side project for someone.
> >
> >     It always has been better in the past, but maybe if the collision
> rate
> >     is kept low it won't matter much. Deletion is horrible, though.
> >
> >     > Changeset appended below.
> >     >
> >     > Bug: https://bugs.openjdk.java.net/browse/JDK-8046362
> >
> >     OK, thanks.
> >
> >     --
> >     Andrew Haley  (he/him)
> >     Java Platform Lead Engineer
> >     Red Hat UK Ltd. <https://www.redhat.com>
> >     https://keybase.io/andrewhaley
> >     EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> >
>
>
>


More information about the core-libs-dev mailing list