RFR: 8221836: Avoid recalculating String.hash when zero
shade at redhat.com
Mon Apr 8 08:56:11 UTC 2019
On 4/8/19 10:41 AM, Claes Redestad wrote:
> 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, 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.
Regardless, I think this change does not carry its weight. Introducing special paths for handling
something as obscure as zero hash code, which then raises questions about correctness (I had hard
time convincing myself that code is concurrency-safe), seems rather odd to me. It is a sane
engineering tradeoff to make code more maintainable with accepting performance hit in 2^(-32) of cases.
More information about the core-libs-dev