RFR: 8221723: Avoid storing zero to String.hash

[Claes Redestad]

We could remove value.length > 0 and be net-neutral in #branches
for the general slow path (calculate the hash), but that would add a
branch to the emptyString.hashCode() _fast path_ (consistently add
~0.5ns/op on my workstation with provided micro). We've been bitten
before that adding cost to "".hashCode() has effect on some benchmarks,
e.g., our internal XML implementation has some odd corner cases.

Thus optimizing away a single branch from the calculating slow path (5%
for the empty string, quickly diminishing overhead with increased String
size) didn't seem worthwhile to me.

/Claes

On 2019-04-01 19:13, Martin Buchholz wrote:
> I'm confused.
> 
> We have always had
>           if (h == 0 && value.length > 0) {
> so we have already been special-casing empty strings (maybe we should 
> stop?).
> 
> Java has guaranteed that string literals are unique strings, but the 
> empty string is not special in this regard.  Archiving any string 
> literal and restoring it later should be identity-preserving, no?
> 
> Whenever we test or benchmark zero-hash Strings, there are 3 cases that 
> should be covered - literal "", new String(), and (rare!) non-empty 
> Strings that happen to hash to 0.
> 
> We could avoid archiving those rare non-empty Strings that happen to 
> hash to 0 at archive time if it saved us a branch at runtime.