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
