RFR: 8221723: Avoid storing zero to String.hash

[dean.long at oracle.com]

OK, I guess there's no ideal solution.  Adding a separate "not-computed" 
boolean adds space, and using a different sentinel value for 
"not-computed" would probably be slower on CPUs that have a fast 
compare-and-branch-against-zero instruction.

dl

On 4/1/19 12:55 PM, Martin Buchholz wrote:
> The spec says that "".hashCode() must be 0.
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/String.html#hashCode()
>
>
> On Mon, Apr 1, 2019 at 12:51 PM <dean.long at oracle.com 
> <mailto:dean.long at oracle.com>> wrote:
>
>     Wouldn't it be better to write a non-0 value when the computed
>     hash code
>     is 0, so we don't have to recompute it?  Is there some advantage to
>     writing 0 instead of any other value, such as 1?
>
>     dl
>
>     On 4/1/19 4:57 AM, Claes Redestad wrote:
>     > Hi,
>     >
>     > when a String has a calculated hash code value of 0, we
>     recalculate and
>     > store a 0 to the String.hash field every time (except for the empty
>     > String, which is special cased). To make String objects more
>     amenable to
>     > storage in shared read-only memory, e.g., CDS archives, we
>     should avoid
>     > this redundant store.
>     >
>     > Bug: https://bugs.openjdk.java.net/browse/JDK-8221723
>     > Webrev: http://cr.openjdk.java.net/~redestad/8221723/
>     >
>     > Testing: tier1-3, no regression on existing and new StringHashCode
>     > micros
>     >
>     > /Claes
>     >
>