Draft JEP on enhanced volatiles

[Remi Forax]

On 02/07/2014 09:44 PM, Brian Goetz wrote:
> It's about time we brought atomic ops out of the shadows of Unsafe and 
> into the programming model proper!  It was a good compromise ten years 
> ago to stuff these into Unsafe, but its time for these features to 
> grow up.
>
> Specific to this proposal, I like how the VolatileXxx interface 
> approach allows us to add new fencing modes and/or atomic operations 
> should we discover that the initial set is deficient. I also like how 
> this potentially gives us a consistent story for volatile semantics on 
> array elements.
>
> I can see a clean and straightforward implementation here at all the 
> required touch points: language spec, memory model, type system, 
> compiler, and VM runtime, and none of them require any special magic. 
> (Having spent some time exploring this design space myself, I think 
> the proposed surfacing is the least objectionable and most transparent 
> of the options that I've seen.)

Brian,
can you be a little more specific and provide the way 
foo.volatile.compareAndSet is compiled with this example:
class Linked {
   volatile Node head;

   public void add(String element) {
     for(;;) {
        Node oldHead = head.volatile.get();
        Node newNode = new Node(element, oldHead);
        if (head.volatile.compareAndSet(oldHead, newNode)) {
          return;
        }
     }
   }
}

I will be very happy to see how you solve the different issues because
i've also spent some times thinking on how the .volatile syntax can be 
implemented:
   - what is the signature of the method compareAndSet, and how you 
fight the generics erasure ?
   - how do you remove the extra-level of indirection if head is a 
VolatileXXX,
     because accessing to the value is this.head.payload and not this.head ?
   - what LinkedClass.class.getDeclaredField("head").getType() returns ?

regards,
Rémi