RFR: 8221836: Avoid recalculating String.hash when zero

[Claes Redestad]

Right, this and possibly reducing latency when running with String
deduplication enabled might be the more tangible benefits. Removing
a cause for spurious performance degradations is nice, but mainly
theoretical. There's likely a pre-existing negative interaction
between string dedup and String archiving that would need to be
resolved either way.

I've simplified the patch somewhat and folded set_hash/hash into
hash_code (since direct manipulation of the hash field should be
avoided), along with a comment to try and explain and caution about the
data race:

http://cr.openjdk.java.net/~redestad/8221836/open.02/

Thanks!

/Claes

On 2019-04-08 12:24, Peter Levart wrote:
> I think the most benefit in this patch is the emptyString.hashCode() 
> speedup. By holding a boolean flag in the String object itself, there is 
> one less de-reference to be made on fast-path in case of empty string. 
> Which shows in microbenchmark and would show even more if code iterated 
> many different instances of empty strings that don't share the 
> underlying array invoking .hashCode() on them. Which, I admit, is not a 
> frequent case in practice, but hey, it is a speedup after all.
> 
> Regards, Peter