----- Mail original ----- > De: "Claes Redestad" <claes.redes...@oracle.com> > À: "Dean Long" <dean.l...@oracle.com>, "Martin Buchholz" <marti...@google.com> > Cc: "core-libs-dev" <core-libs-dev@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.l...@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.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 >>> > >>>
