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

[David Holmes]

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 <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
>>>
>>
>>
>>