On Tue, 11 Mar 2025 11:19:13 GMT, Per Minborg <pminb...@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
