Draft JEP on enhanced volatiles

[Benedict Elliott Smith]

>
> Is there anyway to extend the notion/contract of volatile to access to
> array elements.


>From Doug's original email

We also expect to allow volatile operations on array elements in addition
> to fields.



I'm quite excited about these changes, it looks like a great way to provide
support outside of unsafe.




On 7 February 2014 21:25, Frost, Gary <Gary.Frost at amd.com> wrote:

>
>
> WRT to volatile.
>
> Is there anyway to extend the notion/contract of volatile to access to
> array elements.
>
> So of course
>
> volatile int[] arr = new int[2];
>
> Just offers the contract to the array reference 'arr'
>
> What about multiple threads wanting some contract between their uses of
>  arr[1] and arr[2]?
>
> Just thought I would throw this into the mix..
>
> Gary
> -----Original Message-----
> From: core-libs-dev-bounces at openjdk.java.net [mailto:
> core-libs-dev-bounces at openjdk.java.net] On Behalf Of Brian Goetz
> Sent: Friday, February 07, 2014 2:45 PM
> To: Doug Lea; core-libs-dev
> Subject: Re: Draft JEP on enhanced volatiles
>
> 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.)
>
> Minor nits called out inline.
>
> Otherwise, Reviewed (as JDK reviewer) and Endorsed (as area lead).
>
> > We then enable access to corresponding methods for (typically
> > volatile) fields using the ".volatile" prefix. For example:
>
> Is this a prefix or a suffix?
>
> > The ".volatile" syntax is slightly unusual, but we are confident that
> > it is syntactically unambiguous and semantically specifiable.
>
> And, it is reasonably consistent with other similar uses of keywords for
> qualifying access to functionality, such as I.super or Outer.this.
>
> > We also expect to allow volatile
> > operations on array elements in addition to fields.
>
> This calls for the memory model to provide clear semantics for mixed
> accesses, such as volatile write / nonvolatile read.  (The same would be
> true if we permitted the use of the .volatile modifier on nonvolatile
> fields.)
> > Several other alternatives
> > (including those based on field references) have been raised and
> > dismissed as unworkable on syntactic, efficiency, and/or usability
> > grounds
>
> or extensibility grounds.  Many existing proposals might work for the
> operations in front of us today, but not scale as new fencing modes or
> atomic operations are discovered.
>
> > Risks and Assumptions
> > ---------------------
> >
> > We are confident of feasibility.  However, we expect that it will
> > require more experimentation to arrive at compilation techniques that
> > result in efficient enough implementation for routine use in the
> > performance-critical contexts where these constructs are most often
> > needed. The use of method handles may be impacted by and may impact
> > JVM method handle support.
>
> As a limitation, I'd call out that its not obvious how this would scale to
> DCAS.
>
> > A large number of usages in java.util.concurrent (and a few elsewhere
> > in JDK) could be simplified and updated to use this support.
>
> Hooray!
>
>
>
>