for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity

[Peter Levart]

Hi,

Comments inline...

On 3/7/20 10:52 PM, John Rose wrote:
>   Here’s the current draft java doc for java.lang.NonTearable:
>
>> An inline class implements the {@code NonTearable} interface to
>> request that the JVM take extra care to avoid structure tearing
>> when loading or storing any value of the class to a field or array
>> element.  Normally, only fields declared {@code volatile} are
>> protected against structure tearing, but a class that implements
>> this marker interface will never have its values torn, even when
>> they are stored in array elements or in non-{@code volatile}
>> fields, and even when multiple threads perform racing writes.

What about final fields? In current JMM they imply there is a happens 
before between end of constructor (where they are written to) and any 
read of them even after racy publication of an instance. So in effect 
final fields (in non-inline classes) behave as though they are written 
to only once (there's no pre-initialization write that would be 
visible). So I would expect no tearing to be visible too.

Am I right to assume that an inline type whose value is assigned to a 
final field of non-inline type need not be declared NonTearable ?

If I'm right, then final modifier on a field could be used to declare 
inline classes that don't allow tearing.

All fields of inline classes are implicitly final. But does that 
implicitness extends to non-tearability too? For example:

inline class Tearable {
     long x, y;
}

inline class TearableOrNot {
     Tearable t;
}

The 't' field is implicitly final. So does TearableOrNot allow tearing 
the t.x and t.y apart or not? If it doesn't then perhaps this could be a 
way to express non-tearability of inline types. Another option would be 
that fields of inline types are implicitly final but that only means 
they can't be assigned to twice in constructor or even once outside of 
constructor - it doesn't extend to non-tearability. For non-tearability 
they would have to be explicitly declared as final. But that would be 
confusing I think. It is already a little confusing, because in 
non-inline classes, declaring all fields final means that no tearing is 
possible. Not so in inline class where all fields are implicitly final 
already. But that distinction on the 1st level could be learned to live 
with.

Regards, Peter

>>
>> <p> An inline instance of multiple components is said to be "torn"
>> when two racing threads compete to write those components, and one
>> thread writes some components while another thread writes other
>> components, so a subsequent observer will read a hybrid composed,
>> as if "out of thin air", of field values from both racing writes.
>> Tearing can also occur when the effects of two non-racing writes
>> are observed by a racing read.  In general, structure tearing
>> requires a read and two writes (initialization counting as a write)
>> of a multi-component value, with a race between any two of the
>> accesses.  The effect can also be described as if the Java memory
>> model break up inline instance reads and writes into reads and
>> writes of their various fields, as it does with longs and doubles
>> (JLS 17.7).
>>
>> <p> In extreme cases, the hybrid observed after structure tearing
>> might be a value which is impossible to construct by normal means.
>> If data integrity or security depends on proper construction,
>> the class should be declared as implementing {@code NonTearable}.
> Also, we could add a paragraph giving full disclosure about the
> meaninglessness of having non-inlines implement NonTearable,
> or maybe in the end we can position NonTearable in a
> place where non-inlines cannot implement it.  I’m inclined to
> leave it out for now, at least until we figure out the shape of the
> type hierarchy immediately under Object.
>
> Comments?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20200314/ad7a9c8b/attachment.htm>