RFR: 8221723: Avoid storing zero to String.hash

[Remi Forax]

----- Mail original -----
> De: "Claes Redestad" <claes.redestad at oracle.com>
> À: "Dean Long" <dean.long at oracle.com>, "Martin Buchholz" <martinrb at google.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Lundi 1 Avril 2019 22:44:46
> Objet: Re: RFR: 8221723: Avoid storing zero to String.hash

> 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])

Also the header of the underlying array (the array of bytes/chars) has space for a hashCode (the system one) but that value is never visible from the user POV,
so you can use one bit of it.

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

Rémi

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