Re: RFR: 8354300: Fields in String are not trusted

2025-04-18 Thread ExE Boss
On Mon, 14 Apr 2025 18:09:35 GMT, Chen Liang wrote: >> Hello Per, I'm not too familiar with runtime compiler optimizations. So >> consider this as a basic question. >> >>> This means the VM can trust these fields to never change which enables >>> constant folding optimizations. >> >> If I'm

Re: RFR: 8354300: Fields in String are not trusted

2025-04-18 Thread Vladimir Ivanov
On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg wrote: > This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and > `j.l.String.hashIsZero`. This means the VM can trust these fields to never > change which enables constant folding optimizations. > > This PR is tested in tier1, t

Re: RFR: 8354300: Fields in String are not trusted

2025-04-16 Thread Per Minborg
On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg wrote: > This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and > `j.l.String.hashIsZero`. This means the VM can trust these fields to never > change which enables constant folding optimizations. > > This PR is tested in tier1, t

Re: RFR: 8354300: Fields in String are not trusted

2025-04-16 Thread Per Minborg
On Wed, 16 Apr 2025 05:38:59 GMT, Chen Liang wrote: >> yes ! I would write >> "given the current implementation of hashCode(), marking hasIsZero @Stable >> is not useful for constant folding, as the field `hash` of value '0' is read >> first." > > Yep. To be more exact, JIT anticipates a read o

Re: RFR: 8354300: Fields in String are not trusted

2025-04-15 Thread Chen Liang
On Wed, 16 Apr 2025 05:12:28 GMT, Rémi Forax wrote: >> src/java.base/share/classes/java/lang/String.java line 183: >> >>> 181: * us to avoid recalculating this. >>> 182: */ >>> 183: @Stable >> >> Suggestion: >> >> // Marking hashIsZero stable is meaningless, as a read of `0`

Re: RFR: 8354300: Fields in String are not trusted

2025-04-15 Thread Rémi Forax
On Wed, 16 Apr 2025 00:01:18 GMT, Chen Liang wrote: >> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and >> `j.l.String.hashIsZero`. This means the VM can trust these fields to never >> change which enables constant folding optimizations. >> >> This PR is tested in tier

Re: RFR: 8354300: Fields in String are not trusted

2025-04-15 Thread Chen Liang
On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg wrote: > This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and > `j.l.String.hashIsZero`. This means the VM can trust these fields to never > change which enables constant folding optimizations. > > This PR is tested in tier1, t

Re: RFR: 8354300: Fields in String are not trusted

2025-04-15 Thread Chen Liang
On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg wrote: > This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and > `j.l.String.hashIsZero`. This means the VM can trust these fields to never > change which enables constant folding optimizations. > > This PR is tested in tier1, t

Re: RFR: 8354300: Fields in String are not trusted

2025-04-14 Thread Chen Liang
On Mon, 14 Apr 2025 15:46:54 GMT, Jaikiran Pai wrote: >> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and >> `j.l.String.hashIsZero`. This means the VM can trust these fields to never >> change which enables constant folding optimizations. >> >> This PR is tested in ti

Re: RFR: 8354300: Fields in String are not trusted

2025-04-14 Thread Aleksey Shipilev
On Mon, 14 Apr 2025 15:46:54 GMT, Jaikiran Pai wrote: > It then means that the other field will never move out of its initial value > and thus will never be considered "stable". For all non-zero hashcodes, it matters that `hash` would be constant-foldable, which means `if (h == 0 && !hashIsZe

Re: RFR: 8354300: Fields in String are not trusted

2025-04-14 Thread Chen Liang
On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg wrote: > This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and > `j.l.String.hashIsZero`. This means the VM can trust these fields to never > change which enables constant folding optimizations. > > This PR is tested in tier1, t

Re: RFR: 8354300: Fields in String are not trusted

2025-04-14 Thread Aleksey Shipilev
On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg wrote: > This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and > `j.l.String.hashIsZero`. This means the VM can trust these fields to never > change which enables constant folding optimizations. > > This PR is tested in tier1, t

Re: RFR: 8354300: Fields in String are not trusted

2025-04-14 Thread Per Minborg
On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg wrote: > This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and > `j.l.String.hashIsZero`. This means the VM can trust these fields to never > change which enables constant folding optimizations. > > This PR is tested in tier1, t

Re: RFR: 8354300: Fields in String are not trusted

2025-04-14 Thread Jaikiran Pai
On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg wrote: > This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and > `j.l.String.hashIsZero`. This means the VM can trust these fields to never > change which enables constant folding optimizations. > > This PR is tested in tier1, t

RFR: 8354300: Fields in String are not trusted

2025-04-14 Thread Per Minborg
This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations. This PR is tested in tier1, tier2, and tier3 which all pass. - Commit messages: