Re: RFR: 8221723: Avoid storing zero to String.hash

Hi Peter, first: neat trick! On 2019-04-02 12:56, Peter Levart wrote: Hi Claes, I also think that the variant shown below should be compatible with existing VM code that "injects" hash value. No changes necessary, right? Kind of. If an injector forgets setting the hashIsZero bit, it'd just

Re: RFR: 8221723: Avoid storing zero to String.hash

Hi Claes, I also think that the variant shown below should be compatible with existing VM code that "injects" hash value. No changes necessary, right? Peter On 4/2/19 12:53 PM, Peter Levart wrote: Hi Claes, On 4/2/19 10:29 AM, Claes Redestad wrote: Hi Peter, On 2019-04-01 23:54, Peter Lev

Re: RFR: 8221723: Avoid storing zero to String.hash

Hi Claes, On 4/2/19 10:29 AM, Claes Redestad wrote: Hi Peter, On 2019-04-01 23:54, Peter Levart wrote: 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 r

Re: RFR: 8221723: Avoid storing zero to String.hash

Hi Peter, On 2019-04-01 23:54, Peter Levart wrote: 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 est

Re: RFR: 8221723: Avoid storing zero to String.hash

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, sin

Re: RFR: 8221723: Avoid storing zero to String.hash

On Apr 1, 2019, at 12:50 PM, 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? Zero is the easiest sentinel value becau

Re: RFR: 8221723: Avoid storing zero to String.hash

- Mail original - > De: "Claes Redestad" > À: "Dean Long" , "Martin Buchholz" > Cc: "core-libs-dev" > Envoyé: Lundi 1 Avril 2019 22:44:46 > Objet: Re: RFR: 8221723: Avoid storing zero to String.hash > We actually looked at

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]) That'd be a larger endeavor, though, since there are places in VM that calculates and

Re: RFR: 8221723: Avoid storing zero to String.hash

On 4/1/19 10:08 PM, Brian Goetz wrote: > There's another reason to avoid these writes, besides CDS optimizations: > do-nothing writes generate > useless card mark activity. Not for primitive stores, like hash code. But you can construct a funny workload where storing zero hash code would false-s

Re: RFR: 8221723: Avoid storing zero to String.hash

There's another reason to avoid these writes, besides CDS optimizations: do-nothing writes generate useless card mark activity. On 4/1/2019 7: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 (

Re: RFR: 8221723: Avoid storing zero to String.hash

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: Th

Re: RFR: 8221723: Avoid storing zero to String.hash

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

Re: RFR: 8221723: Avoid storing zero to String.hash

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, w

Re: RFR: 8221723: Avoid storing zero to String.hash

On 2019-04-01 20:01, Martin Buchholz wrote: Let me try again...  We exclude 0-hash Strings from archiving because we might write to the hash field, BUT the existing guard value.length > 0 ensures that won't happen for empty Strings ... so WHY were we excluding empty Strings from archiving? I

Re: RFR: 8221723: Avoid storing zero to String.hash

Let me try again... We exclude 0-hash Strings from archiving because we might write to the hash field, BUT the existing guard value.length > 0 ensures that won't happen for empty Strings ... so WHY were we excluding empty Strings from archiving? On Mon, Apr 1, 2019 at 10:32 AM Claes Redestad wr

Re: RFR: 8221723: Avoid storing zero to String.hash

We could remove value.length > 0 and be net-neutral in #branches for the general slow path (calculate the hash), but that would add a branch to the emptyString.hashCode() _fast path_ (consistently add ~0.5ns/op on my workstation with provided micro). We've been bitten before that adding cost to ""

Re: RFR: 8221723: Avoid storing zero to String.hash

I'm confused. We have always had if (h == 0 && value.length > 0) { so we have already been special-casing empty strings (maybe we should stop?). Java has guaranteed that string literals are unique strings, but the empty string is not special in this regard. Archiving any string literal

Re: RFR: 8221723: Avoid storing zero to String.hash

Hi Jiangli, On 2019-04-01 17:21, Jiangli Zhou wrote: On Mon, Apr 1, 2019 at 4:59 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

Re: RFR: 8221723: Avoid storing zero to String.hash

On 2019-04-01 15:28, Claes Redestad wrote: On 2019-04-01 15:17, Pavel Rappo wrote: On 1 Apr 2019, at 13:36, Claes Redestad wrote: Makes sense? It does, thanks. I wonder though what portion of strings in a typical app has a calculated `hash` of 0? My naive estimate would be 1E-9. Unless

Re: RFR: 8221723: Avoid storing zero to String.hash

On 2019-04-01 15:17, Pavel Rappo wrote: On 1 Apr 2019, at 13:36, Claes Redestad wrote: Makes sense? It does, thanks. I wonder though what portion of strings in a typical app has a calculated `hash` of 0? My naive estimate would be 1E-9. Unless I'm mistaken, is that really of concern? Speci

Re: RFR: 8221723: Avoid storing zero to String.hash

Hi Aleksey, On 2019-04-01 15:03, Aleksey Shipilev wrote: On 4/1/19 1:57 PM, Claes Redestad wrote: 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 m

Re: RFR: 8221723: Avoid storing zero to String.hash

> On 1 Apr 2019, at 13:36, Claes Redestad wrote: > > Makes sense? It does, thanks. I wonder though what portion of strings in a typical app has a calculated `hash` of 0? My naive estimate would be 1E-9. Unless I'm mistaken, is that really of concern?

Re: RFR: 8221723: Avoid storing zero to String.hash

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

Re: RFR: 8221723: Avoid storing zero to String.hash

Hi Pavel, On 2019-04-01 14:20, Pavel Rappo wrote: Hi Claes, To make String objects more amenable to storage in shared read-only memory, e.g., CDS archives, we should avoid this redundant store. Could you please elaborate on that? currently, heap archiving excludes Strings with hash 0 from

Re: RFR: 8221723: Avoid storing zero to String.hash

Hi Claes, > To make String objects more amenable to storage in shared read-only memory, > e.g., CDS archives, we should avoid this redundant store. Could you please elaborate on that?

RFR: 8221723: Avoid storing zero to String.hash

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 red