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

[Daniel Heidinga]

Making it a property of the type makes sense and covers the otherwise missing case of the creator of the type wanting to express that it's never torn.  For inline fields there's already both the LvsQ distinction and the "volatile" keyword to ensure they can't be torn (though it comes with some additional baggage of memory barriers).  Arrays can also use the LvsQ distinction to prevent tearing.

 

> I’d like to

> suggest that IdentityObject implements NonTearable, so that

> bounds like Record & NonTearable allow identity and inline

 

Allowing both to implement the interface is fine from our perspective.  Implementation wise it's trivial to convert NonTearable to a bit and inherit it when creating subclasses.  And it makes sense at an API level.

 

The one caution here is in how we present the NonTearable interface when used with Identity classes as the interface won't protect users from data races - they will still need safe publication or see inconsistent values - while it will protect Inline classes.

 

--Dan

----- Original message -----
From: John Rose <john.r.r...@oracle.com>
Sent by: "valhalla-spec-experts" <valhalla-spec-experts-boun...@openjdk.java.net>
To: "Rémi Forax" <fo...@univ-mlv.fr>
Cc: valhalla-spec-experts <valhalla-spec-experts@openjdk.java.net>
Subject: [EXTERNAL] Re: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity
Date: Sat, Mar 7, 2020 6:18 PM
 
On Mar 7, 2020, at 2:22 PM, fo...@univ-mlv.fr wrote:

 

Marker interface are usually problematic because:
- they can inherited, for inline classes, you can put them on our new kind of abstract class, which will make things just harder to diagnose.

 

As always the flexibility of inheritance cuts both ways.

Suppose I define AbstractSlice with subtypes MemorySlice,

ArraySlice, etc. and I intend it for secure applications.

I then mark AbstractSlice as NonTearable, and all its subs

are therefore also NonTearable.  You cannot do that with

an ad hoc keyword, even if you want to.  You have to make

sure that every concrete subtype mentions the keyword.

 

It’s a trade-off, of course, but for me the cost of a new keyword

pushes me towards using types making the property inherited.

It’s a decision which falls squarely in the center of the language.

 

- they can be uses as a type, like Serializable is used where it should not.
 By example, what an array of java.lang.NonTearable means exactly. There is a potential for a lot of confusion. 

 

Again, if I have an algorithm that works for a range of value

types (via an interface or abstract super), I can express the

requirement that the inputs to the algorithm be non-tearable,

using subtypes.  For example, the bound (Record & NonTearable)

expresses and enforces the intention that the algorithm will

operate on non-tearable record values.

 

 

and in the specific case of NonTerable, a non inline class can implement it, again creating confusion.

 

The confusion comes from the incomplete story here.  I’d like to

suggest that IdentityObject implements NonTearable, so that

bounds like Record & NonTearable allow identity and inline

objects.

 

— John