Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8084372 | emb-9 | Aleksey Shipilev | P4 | Resolved | Fixed | team |
We might want to clean up the String.hashCode() implementation.
Let the patch speak for itself:
http://cr.openjdk.java.net/~shade/8058643/webrev.01/
It improves the readability, and also does not affect performance much:
http://cr.openjdk.java.net/~shade/8058643/StringHashCode.java
The improvement in nonCached case seems to be due to slightly better code generation, if one can closely examine the assembly:
http://cr.openjdk.java.net/~shade/8058643/baseline.perfasm
http://cr.openjdk.java.net/~shade/8058643/patched.perfasm
It seems to be because we have one less branch checking for value.length.
Let the patch speak for itself:
http://cr.openjdk.java.net/~shade/8058643/webrev.01/
It improves the readability, and also does not affect performance much:
http://cr.openjdk.java.net/~shade/8058643/StringHashCode.java
The improvement in nonCached case seems to be due to slightly better code generation, if one can closely examine the assembly:
http://cr.openjdk.java.net/~shade/8058643/baseline.perfasm
http://cr.openjdk.java.net/~shade/8058643/patched.perfasm
It seems to be because we have one less branch checking for value.length.
- backported by
-
JDK-8084372 (str) Improve String.hashCode implementation
-
- Resolved
-
- duplicates
-
JDK-8141506 optimization in String.hashCode()
-
- Closed
-