Ensuring atomicity of long values

[Remi Forax]

> From: "-" <liangchenblue at gmail.com>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Saturday, October 21, 2023 8:37:19 AM
> Subject: Ensuring atomicity of long values

> Hello valhalla community,
> While looking at the new non-atomic model that allows flattening in the heap, I
> wonder if we can represent null-restricted 64-bit atomic data where the most
> and the least significant bits shouldn't tear.

> An example would be a modifier collection, where some modifier bits are
> dependent on others, while 0 (the default) is a valid value. One such
> dependency present in JDK itself is that ABSTRACT modifier must be set if
> INTERFACE modifier is, and at most one of PUBLIC, PRIVATE, or PROTECTED
> modifiers can be set. Such constraints can happen across the 32-bit boundary,
> and thus primitive long is not a suitable choice for its non-atomicity.

> How should I declare a value class that ensures atomicity of the null-restricted
> long value it contains? And how can a correct declaration consistently benefit
> from the 64-bit atomic operations offered on modern architectures?

By default, a null restricted value class does not allow tearing by default so wrapping a long should be enough (I hope). 

class LongWrapper { 
long value; 
implicit LongWrapper(); 
LongWrapper(long value) { this.value = value; } 
} 

class Foo { 
LongWrapper! w; // this is a non-tearing long 
} 

>From the spec POV, there is no garantee that an instance will not be a pointer instead of the direct value but given that Java only works on platforms (even 32 bits) that are able to write 64 bits atomically (otherwise you can not implement the VarHandle API), practically, it should be ok. 

> Truly curious,
> Chen Liang

regards, 
Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20231021/55f53f34/attachment.htm>