RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]

[John R Rose]

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg <pminborg at 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