New candidate JEP: 502: Stable Values (Preview)

[Maurizio Cimadamore]

Hi Alan,
I think it's fair to say that the StableValue API is a safe view of the 
`@Stable` JVM internal annotation that has been around for quite some 
time. If you look inside the JDK code, you will see that `@Stable` is 
used frequently in conjunction with lazily populated caches of method 
handles and var handles, as that's where it gives most benefits (method 
handles like to be constant, but deferred init makes constant-ness 
impossible).

While we started working on this for MH/VH-related use cases (for 
instance, FFM's jextract will be a big user of stable values), we also 
realized that this abstraction is actually quite useful in other cases 
too. The class holder idiom is quite widespread when it comes to lazy 
init. I think the StableValue gives you a more elegant way to do this 
(although, yes, maybe not as elegant as a keyword).

While we're not shy of making language changes, we need to be absolutely 
certain that such language changes are required. This often requires 
consideration that are not merely syntactic -- e.g. because saying `lazy 
Foo` is better than saying `StableValue<Foo>` -- but ones affecting 
semantics (e.g. does having a keywod make some shifting of computation 
that would otherwise not be possible with an API approach) ?

I think John's email on leyden-dev pains some broad strokes of what such 
an evolution would look like:

https://mail.openjdk.org/pipermail/leyden-dev/2025-January/001283.html

My personal opinion is that an API like StableValue would be the 
building block of any language feature that will provide laziness. E.g. 
consider a lazy _instance_ field. How would we make sure that such a 
field is updated at-most-once, and atomically across multiple threads? 
In such cases having something like StableValue seems unavoidable 
(unless one would like to push all this complexity down to the JVM 
level, which I'm not sure buys much).

So, while I can imagine a world where _direct_ use of StableValue 
becomes more niche, I don't think StableValue will really become "obsolete".

I also believe we're at the beginning of this story -- and we're still 
learning of what we can do with stable values. A fruitful avenue of 
exploration will likely be trying to plug stable values in the innards 
of existing dependency injection frameworks. This is another example of 
how _indirect_ use of stable values might benefit the wider ecosystem.

Maurizio

On 22/01/2025 21:53, Alan Snyder wrote:
> The JEP describes StableValue as a step towards deferred immutability, defined as:
>
> "What we are missing is a way to promise that a field will be initialized by the time it is used, with a value that is computed at most once and, furthermore, safely with respect to concurrency. In other words, we need a way to defer immutability.”
>
> What is the roadmap for getting the rest of the way?
>
> StableValue looks to me like an implementation mechanism, something that someday the compiler and JVM might use.
> It does not look like something I would want to use in my source code.
> If introduced as a public API, will StableValue be obsolete soon thereafter?
>
>
>
>
>
>> On Jan 22, 2025, at 7:10 AM, Mark Reinhold <mark.reinhold at oracle.com> wrote:
>>
>> https://openjdk.org/jeps/502
>>
>>   Summary: Introduce an API for stable values, which are objects that
>>   hold immutable data.  Stable values are treated as constants by the
>>   JVM, enabling the same performance optimizations that are enabled
>>   by declaring a field final.  Compared to final fields, however,
>>   stable values offer greater flexibility as to the timing of their
>>   initialization.  This is a preview API.
>>
>> - Mark