RFR: 8221836: Avoid recalculating String.hash when zero

Claes Redestad claes.redestad at oracle.com
Mon Apr 8 15:24:57 UTC 2019

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:




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

More information about the core-libs-dev mailing list