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
