On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg <pminb...@openjdk.org> wrote:
>> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 246 commits: > > - Merge branch 'master' into implement-jep502 > - Clean up exception messages and fix comments > - Rename field > - Rename method and fix comment > - Rework reenterant logic > - Use acquire semantics for reading rather than volatile semantics > - Add missing null check > - Simplify handling of sentinel, wrap, and unwrap > - Fix JavaDoc issues > - Fix members in StableEnumFunction > - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 74: > 72: @Override > 73: public boolean trySet(T value) { > 74: if (wrappedContentAcquire() != null) { IMHO, if our goal is to do: Object content = this.content; if (context != null) return content: synchronized (...) { if (context != null) return content: this.context = ... } Then we might just use a volatile field and synchronized blocks. I don't see an immediate need for using acquire/release semantics -- especially when using a monitor. E.g. this should look more like a classic double checked locking idiom. (but with a stable field to make the first volatile read more efficient in case the field is already set) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993850760
