5 ms·

I don't think he refers to the caching being a bad thing, but that it probably does not affect performance that much, since most Strings are likely to be small

I don't think he refers to the caching being a bad thing, but that it probably does not affect performance that much, since most Strings are likely to be small (and the number of times hashcode is called is also likely to be small). There's also a catch : if the hashcode of the string is 0, the hashcode will be recalculated every time (since the code assumes it has not been cached yet).

moonchrome 11y ago
>There's also a catch : if the hashcode of the string is 0, the hashcode will be recalculated every time (since the code assumes it has not been cached yet). At least that part should be easy to fix by defining a hash function that returns numbers != 0 - even the article says they did it for JVM7 but it's gone in JVM8 - with no explanation ?
- Ironlink 11y ago
  The hash32 implementation in Java 7 was not intended to fix the case where the actual hash value was zero, nor did it have an impact on that case as the hash32 value was stored in a separate field. It was made to decrease the number of hash value collisions in large data structures (hash maps and such). Its replacement is described here: http://openjdk.java.net/jeps/180 http://openjdk.java.net/jeps/180 . Given that most Strings never end up in a large collection, allocating an extra 4 bytes for every one of them was a waste. This post has been edited once for factual correctness.
  - mtdewcmu 11y ago
    It's hard to imagine a situation where the hash function would be so slow as to justify adding 4 bytes to every string.
    - joosters 11y ago
      If your strings are large, then calculating the hash will take time AND the extra 4 bytes for hash storage will be minimal extra overhead. You can easily find good & bad cases for all of these string implementations. They all have tradeoffs.
brandonbloom 11y ago
Can just bit-or 1.
- wolf550e 11y ago
  this halves the number of values. doing if (hashcode == 0) hashcode = 1; removes only one value.

moonchrome 11y ago

>There's also a catch : if the hashcode of the string is 0, the hashcode will be recalculated every time (since the code assumes it has not been cached yet). At least that part should be easy to fix by defining a hash function that returns numbers != 0 - even the article says they did it for JVM7 but it's gone in JVM8 - with no explanation ?

Ironlink 11y ago
The hash32 implementation in Java 7 was not intended to fix the case where the actual hash value was zero, nor did it have an impact on that case as the hash32 value was stored in a separate field. It was made to decrease the number of hash value collisions in large data structures (hash maps and such). Its replacement is described here: http://openjdk.java.net/jeps/180 http://openjdk.java.net/jeps/180 . Given that most Strings never end up in a large collection, allocating an extra 4 bytes for every one of them was a waste. This post has been edited once for factual correctness.
- mtdewcmu 11y ago
  It's hard to imagine a situation where the hash function would be so slow as to justify adding 4 bytes to every string.
  - joosters 11y ago
    If your strings are large, then calculating the hash will take time AND the extra 4 bytes for hash storage will be minimal extra overhead. You can easily find good & bad cases for all of these string implementations. They all have tradeoffs.

brandonbloom 11y ago

Can just bit-or 1.

wolf550e 11y ago
this halves the number of values. doing if (hashcode == 0) hashcode = 1; removes only one value.