On Mon, 30 Jun 2025 13:09:57 GMT, Andrew Haley <a...@openjdk.org> wrote:

>> Scoped values cannot be used early in the JDK boot process because of some 
>> dependencies on System.getProperty(). This dependency should be removed in a 
>> way that allows scoped values to be created (but not necessarily bound) at 
>> any stage during boot.
>> 
>> Also, Scoped Value's constructor has a synchronized block, which limits the 
>> use of scoped values at runtime. Constructing a scoped value should be a 
>> thread-local operation.
>
> Andrew Haley has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Move THREAD_LOCAL_RANDOM_ACCESS into class Cache.Constants

src/java.base/share/classes/java/lang/ScopedValue.java line 802:

> 800:                         return x;
> 801:                     }
> 802:                 };

There's something a bit uncomfortable about initializing hashGenerator in 
ScopedValue's class initializer, then changing it in Constants class 
initializer. Iimmediately clear what the memory model issues. It doesn't of 
course matter if the stale value is used but I think confusing on first sight.

Have you tried dropping the initializer from ScopedValue so it hashGenerator is 
only set by Constants? The ScopedValue constructor can call generateKey if 
hashGenerator is null, and hashGenerator can become a stable field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26019#discussion_r2175414039

Reply via email to