RFR: 8221723: Avoid storing zero to String.hash

[Peter Levart]

On 4/1/19 10:44 PM, Claes Redestad wrote:
> 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.

In addition, this might not be easy from another point of view. You all 
know that there's no synchronization performed when caching the hash 
value. This works, because 32 bits are always read or written 
atomically. If there was another byte to be read or written together 
with 32 bit value, it would be tricky to get the ordering right and 
still keep the performance.

Regards, Peter

>
> /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
>>>     >
>>>
>>