RFR: 8221723: Avoid storing zero to String.hash

[Claes Redestad]

We actually looked at this idea earlier today, and squeezing a "not-
computed" value into String might be "free" since there seems to be a
padding gap on all VM varieties (at least according to JOL estimates[1])

That'd be a larger endeavor, though, since there are places in VM that
calculates and injects the String.hash value.

/Claes

[1] https://openjdk.java.net/projects/code-tools/jol/

On 2019-04-01 22:02, dean.long at oracle.com wrote:
> 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
>>     >
>>
>