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
