RFR: 8351565: Implement JEP 502: Stable Values (Preview)

[Quan Anh Mai]

On Tue, 11 Mar 2025 11:19:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 777:
>> 
>>> 775:         private final IntFunction<? extends E> mapper;
>>> 776:         @Stable
>>> 777:         private final StableValueImpl<E>[] backing;
>> 
>> You can use a backing `@Stable Object[]` instead. It will reduce indirection when accessing this list.
>
> Can you please elaborate a bit more on your proposal @merykitty?

If you have an `@Stable Object[]`, then the elements are also considered `@Stable`. Then you can do something like:

    ReentrantLock[] locks;

    T get(int idx) {
        Object x = backing[idx];
        if (x == null) {
            return compute(idx);
        }
        return unwrap(x);
    }

    T compute(int idx) {
        ReentrantLock lock = locks[idx];
        lock.lock();
        try {
            Object x = backing[idx];
            if (x != null) {
                return unwrap(x);
            }
            T obj = ...;
            backing[idx] = wrap(obj);
            return obj;
        } finally {
            lock.unlock();
        }
    }

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 65:
>> 
>>> 63:     //
>>> 64:     @Stable
>>> 65:     private volatile Object value;
>> 
>> Can we use `acquire`/`release` semantics instead of `volatile`?
>
> Yes we can. However, I am uncertain if the added complexity can motivate any performance benefits. Perhaps on ARM? I can do a benchmark on it.

You can probably use `acquire` only for the first `get` as it is in the fast path. For other I guess `volatile` is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989664004
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1990989622