RFR: 8221836: Avoid recalculating String.hash when zero

Aleksey Shipilev shade at redhat.com
Mon Apr 8 14:55:35 UTC 2019

On 4/8/19 2:44 PM, Peter Levart wrote:
> If you're afraid that a future maintainer of that code would not realize that, then a simple comment
> put into String.hashCode method and java_lang_String::set_hash C++ metohd that would say something
> like the following:
> // only a single field may be modified so that the Object state is updated atomically
> ...is surely going to help him/her keep the String free from bugs...


Famous last words!

Let me try again myself. Benign data race is already creepy enough in its original form. You have to
come up with the overwhelming reason to complicate it even further.

Why introduce this complexity to begin with? That's my argument. The complication of this code gives
us almost nothing in return, why make the change? Without the compelling reason to do it, all this
is just a runaway "hold my beer" micro-optimization exercise, which is fun and instructional, but
should not be pushed to the actual JDK. In other words, just because we *can* it does not follow
that we *should*.


More information about the core-libs-dev mailing list