Ensuring atomicity of long values

[John Rose]

On 21 Oct 2023, at 2:29, forax at univ-mlv.fr wrote:

> Long will never tear, but Long! (note, there is a bang here) will tear. Long! and long have exactly the same semantics with respect to tearing.
> From the spec POV, if you want flattenes on heap you need both a value class with an implicit constructor AND using ! at use site (where the field is declared).

Hmm, Long! also will never tear, until/unless the JDK author of Long
marks the class (somehow) as permitting non-atomic updates.  By default,
updates of both V and V! are free from races.  Only after opt-in
does V! (never V) begin to allow races.  I can’t say with certainty
what the JDK policy will be for making Long tearable, in the end.

It seems safer NOT to declare Long! tearable.  So Long! would be
a little safer than long on platforms which tear long.  But it
is also unclear whether having Long! differ from long this way
is a good thing or not.  So… I can’t say.  Maybe Brian or Dan
has worked out the whole equation for this particular question.

There is a spectrum or journey of opting in: first value class
(discarding identity), then allow zeroes by implicit constructor
(discarding 100% explicit construction), then non-atomicity
(discarding protection against construction by races).  Each
step is a tradeoff: Give something up, get something better.

> After, a specific VM can do heroics and discover that the actual CPU supports atomic 128 bits read/write using vector instructions and decide to store a Long (no bang) as a 128 bits values, 64 for the value and 1 for null or not. But this is a tradeoff, using more memory may backfire.

Ah yes, the 128-bit heroics.  Those will be best when the object payload
uses most or all of those 128 bits.  There are also possible 64.1-bit
heroics which steal the single bit from some condition on the object.
Those are in the realm of STM, and work best if the extra bit only
rarely needs setting.  That line of thought arises from the design
of lazy fields.  Then there are also possible 63-bit heroics involving
unions between immediate and pointer, as we had in the old days of Lisp.

There are old prototypes of 64-N-bit thingies on HotSpot (sort of
like NaN-tagged doubles, but which steal encodings from 64-bit long).
Like the NaN tags, they seem to promise interesting 64-N-bit heroics
for value types, and with a configurable N.

It will be fun to try all out these heroics, someday, on 65-bit types,
and see if they help any use-cases.

A “heroic” which gets by in less than 64 bits seems paradoxical,
but sometimes is applicable if you really don’t expect the values
to inhabit the entire 2^64 bit range, and/or are willing to take
a performance hit on a few values, perhaps because they are rare.
That’s the essential tradeoff of Lisp and Smalltalk small ints.

If you think that is far fetched, ask yourself when there ever
was a Java application which created the full range of possible
java.lang.Long values.  None ever did, because it would require
a peta-scale heap, which Java can’t run on and may never.

To be clear, these are all just the possibilities; nobody is
working on them yet.  We’ve got plenty of more basic heroics
to carry out now, in the Valhalla project.  But the above
considerations suggest to me that our current set of heroics
are just the beginning.  Like it was in the beginning of Java,
when “it is an interpretive language” and “its GC is slower
than hand-managed malloc” were sometimes considered wise
reasons to stay with C.  That cost model was exploded by
HotSpot and other second-generation JVMs.

Maybe there will be a wise principle at first that “Valhalla
values take up more heap space than primitives”.  That shouldn’t
be true if you declare them properly, but there might be cases
where you want to preserve safety or abstraction beyond what
primitives do, and pay for it (at first) with a little heap.
But given a good semantic foundation, such cost models can
go out of date, as the platform adds better and better
optimizations under the covers.  That’s what I hope for Valhalla.