Hi Claes!
Would it make sense to preset hashIsZero = true in the empty string
constructor?
The current code avoids calculating the hashCode for an empty string,
and the new code doesn't seem to do that because hashIsZero = false by
default for each newly constructed copy of the empty string.
With kind regards,
Ivan
On 4/8/19 1:41 AM, Claes Redestad wrote:
Hi,
by adding a bit to String that is true iff String.hash has been
calculated as being 0, we can get rid of the corner case where such hash
codes are recalculated on every call.
Peter Levart came up with a elegant scheme for ensuring that we can keep
using non-volatile stores without explicit fencing and still reap the
benefits of this[1], and I've synced up the hotspot code that deals with
the String.hash value to mirror that logic.
Bug: https://bugs.openjdk.java.net/browse/JDK-8221836
Webrev: http://cr.openjdk.java.net/~redestad/8221836/open.01/
Since there exists small padding gaps in the current object layout of
strings (on all VM bitness and compressed oops varieties), adding this
boolean does not add any extra footprint per String instance.
Testing: tier1-3, verified a speed-up in targeted microbenchmarks.
Thanks!
/Claes
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059480.html
--
With kind regards,
Ivan Gerasimov
