New candidate JEP: 502: Stable Values (Preview)

[Maurizio Cimadamore]

On 27/02/2025 10:43, David Gregory wrote:
> Hi Maurizio,
>
> On 21/02/2025 18:42, Maurizio Cimadamore wrote:
>> There's different meaning for the word "trusted". If, by that, you 
>> mean that fields of type StableValue<X> should be trusted the same 
>> way that record components are trusted (e.g. where "final" really 
>> means "final"), this is something we can do. I believe the prototype 
>> we have today does that to some extent -- but we don't know yet 
>> whether that "hack" will be made official :-) 
>
> That's awesome! Does creating a StableValue allocate an object, or is 
> StableValue optimised away to some bytecode construct by javac?
>
> The reason that I ask is that I wanted to know whether implementers of 
> other JVM languages could use this feature - for example, could we 
> mark a field as stable using some access modifier at the bytecode 
> level without using the StableValue API?

It creates an object. One of the areas we'd like to explore some more is 
the Leyden connection -- maybe some of these objects can be eliminated 
if we know what they are set to (e.g. during a training run).


>
> I watched Per's talk at Devoxx and he suggested that it would be 
> difficult to allow fields outside of JDK classes to be marked stable 
> for security reasons, so I suspect the answer to this is no?
>
> If not, is this a possibility in the future when "trust" and integrity 
> of final fields is more fully fleshed out at the JVM level?

Exposing stable fields directly to user code would not be safe, correct.

That said, there might be other features that the language could expose 
that might provide similar functionalities. For instance, a "lazy" 
keyword. Now, it is important to understand that, while there might be 
an API-free path to get to lazy _static_ fields (e.g. using condy), lazy 
_instance_ fields are a completely different can of worms -- and you 
will end up reinventing the same coping mechanisms devised by the 
StableValue API (to ensure at-most once semantics across multiple threads).

So, our hope is that if, in the future, the language would like to 
explore a more direct way to model laziness, stable values could be used 
as a building block by the compiler. And what you write below goes in 
that direction -- we are surely interested to know how well stable value 
might be used in a backend of a compiler (and the addition of the 
imperative access API was -- at least in part -- motivated by that use 
case).

Thanks
Maurizio

>
> I've written up a gist explaining how this feature might be used by 
> functional languages, using AtomicReference as a stand-in for 
> StableValue, since the API is pretty similar: 
> https://urldefense.com/v3/__https://gist.github.com/DavidGregory084/6939b85b6fd3ccfdfc83e05011697ed4__;!!ACWV5N9M2RV99hQ!PrDYhBcrlkUbA_-yIoaBtq6WIZgfaEVacr_MCkC2CWner3RCKVjZ7l8yUr9w2kbrIw4Q-Q37k65n-qSVEa2GWE_MSg$ 
>
> The existing StableValue JEP will work great for me personally as the 
> translation between my "data" and the underlying JVM classes is not as 
> direct as e.g. Scala's case class or Kotlin's data class, and I'd 
> rather it was possible to make more programs stack-safe, even if it 
> requires allocating lots of StableValues, but I am developing more of 
> a teaching language so performance is not exactly paramount for me!
>
> However, it would be great if everybody could get their hands on 
> "stable" - e.g. the "next" field in Scala's List cons cell is an 
> amazing candidate for stable as it's only mutated immediately after 
> creation, like in List#map:
>
> https://urldefense.com/v3/__https://github.com/scala/scala/blob/a2090009c4fc3791b545a257ec6d1431e87cb1f4/src/library/scala/collection/immutable/List.scala*L245__;Iw!!ACWV5N9M2RV99hQ!PrDYhBcrlkUbA_-yIoaBtq6WIZgfaEVacr_MCkC2CWner3RCKVjZ7l8yUr9w2kbrIw4Q-Q37k65n-qSVEa1nTmvCuA$ 
>
> Thanks,
>
> David Gregory
>