3 ms·
>If left unoverridden, it only yields a description of it’s class and location in memory It contains the hashCode(), not the memory location. The default imple
by josefx 7y ago
>If left unoverridden, it only yields a description of it’s class and location in memory
It contains the hashCode(), not the memory location. The default implementation of hashCode could use a memory location to generate the hash, however that isn't the case in all implementations. OpenJDK seems to have used an RNG by default in the past and currently derives a value from the thread state[1]
[1]https://srvaroa.github.io/jvm/java/openjdk/biased-locking/2017/01/30/hashCode.html https://srvaroa.github.io/jvm/java/openjdk/biased-locking/20...
- benmmurphy 7y agofor most implementations it would not be possible to use the location in memory because most java garbage collectors will move stuff around in memory. they could use the location initially and cache it afterwards but this would seem tricky to do without breaking the hash code contract.
- josefx 7y agoI think the code also has the option to read and store the address. However I also think it would have other problems. Heaps with less than 4GB size would put a limit on possible hash code values and object alignment requirements would make it even worse, so you never get use out of the full 32 bit hashCode. Then you have generational GCs and if I understand those correctly you could end up with a lot of objects that started out at the same address and if you call hashCode on them before they are moved to a long lived generation you almost guarantee a large amount of hash collisions down the line.
- selbekk 7y agoThanks for the reply - the author (who doesn't have a user here) agreed completely, and the article has been changed to reflect that.