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 Hi again Per! Here are some brief notes from our face-to-face chat at JavaOne. Debuggers want/need a "hook" for tentative evaluation of stables. It is an error for a debugger to trigger stable value decisions. This applies mainly to stable lists because of `toString`. Just how "mutable" is a stable list? How "eager to decide"? Which methods (if any) are tentative: `toString` / `equals` / `hashCode` ? Currently in the PR, all are decisive. This might be a case of the “wrong default”. Maybe refactor composites to expose systematically "tenative" access API: - Less universal: SV.list(My::compute) => List<T> - More universal; SV.stableList(My::compute) => List<StableSupplier<T>> BTW, it’s easy to understand a stable-list as a list of stables. But let’s be sure to leave room for a more compact data structure. A compact stable-list is a list of stable views into a backing array. The backing array looks like `@Stable private T[] resolvedValues`. Not `private final List<StableValue<T>> stableValues`. For the record: I think this is sufficient for correctness: Use `getAcquire` (resp. `releaseSet`) for all stable reads (resp. writes. Do the `releaseSet` inside a mutex that serializes computation. Add a re-entrancy check in the mutex and throw on vicious cycles. I do NOT think `volatile` is necessary; it has too many fences. It is a safe default for a naked variable. But the stable variables are encapsulated, and do not need aggressive fences. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2735079141
