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.l...@oracle.com
<mailto:dean.l...@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
>
