Hi Martin,
On 8/02/2020 3:10 am, Martin Buchholz wrote:
I explored System.identityHashCode (see below).
System.identityHashCode is a VM call that is potentially very expensive.
In the worst-case it triggers monitor inflation.
Cheers,
David
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 <d...@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 <a...@redhat.com
<mailto:a...@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
