RFR: 8360884: Better scoped values

[Chen Liang]

On Fri, 27 Jun 2025 14:32:11 GMT, Andrew Haley <aph at 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.

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

> 709:     // This method exists only so that we can generate keys early in
> 710:     // the boot cycle, before the class j.u.c.ThreadLocalRandom has
> 711:     // been initialized.

I recommend also adding "or System.getProperty is accessible" here. I think we need to describe in detail how this dependency system works:

1. Cache size depends on System.getProperty (Reason for original failure)
2. Hash depends on ThreadLocalRandom initialization

So we want to convey that in early boot, we can create SV, but we cannot bind/query it. No matter what implementation class model we choose, I think we should document this two-stage initialization process of:

1. Early boot, can create SV, cannot use it
2. 2 dependencies ready, can now bind/query SV.

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

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