-
Enhancement
-
Resolution: Fixed
-
P4
-
11, 17, 21, 23, 24
-
b12
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8341837 | 23.0.2 | Aleksey Shipilev | P4 | Resolved | Fixed | b03 |
Basically:
private @Stable int hash;
public int hashCode() {
int hc = hash;
if (hc == 0) {
hc = hash = initHashCode();
}
return hc;
}
[~aboldtch] showed that if the write to the stable field is outlined to a method annotated with @DontInline then the would-be regression (in the specific benchmark) disappears. A good diagnostic, but not a universally compelling workaround if the path that writes to the stable field is reasonably hot. It seems the ideal would be if C2 could emit the membar only for branches where the write happens (with a fallback to emit at the exit in more complex cases).
Filing this as an enhancement initially, but it's not unreasonable to consider this as a bug/performance regression since we might have inadvertently regressed aarch64 in a few places by applying @Stable backed primarily on evidence from x64 setups.
- backported by
-
JDK-8341837 Fix memory barriers for @Stable fields
-
- Resolved
-
- duplicates
-
JDK-8300143 Remove redundant barriers when final and stable fields written in ctor
-
- Closed
-
- is blocked by
-
JDK-8337876 [IR Framework] Add support for IR tests with @Stable
-
- Resolved
-
- relates to
-
JDK-8335274 SwitchBootstraps.ResolvedEnumLabels.resolvedEnum should be final
-
- Resolved
-
-
JDK-8330465 Stable Values (Preview)
-
- In Progress
-
-
JDK-8031818 Experimental VM flag for enforcing safe object construction
-
- Resolved
-
-
JDK-8306075 Micro-optimize Enum.hashCode
-
- Resolved
-
- links to
-
Commit(master) openjdk/jdk23u/1c812b5d
-
Commit(master) openjdk/jdk/74fdd686
-
Review(master) openjdk/jdk23u/122
-
Review(master) openjdk/jdk/19635