[jmm-dev] Update to description of JEP 193: Enhanced Volatiles

[Brian Goetz]

I think you are misunderstanding the underlying goal here, David, which 
may explain your reaction.

The goal here was never "let's add more syntax".  It was to have an 
alternative to Unsafe for exposing esoteric, low-level memory-access 
features in a regular, safe, reliably efficient, and specifiable way. 
Just as only .00001% of Java developers ever use Unsafe (or should, 
anyway), we don't expect the audience for this feature to be very large. 
  MethodHandles are an excellent analogy; they are a tool intended for 
writers of compilers, language runtimes, and other low-level components. 
  VarHandles are similar; this is a tool for people writing nonblocking 
algorithms and other fancy library code, without having to resort to 
Unsafe (which is currently the only option.)

The proposed language syntax in the original JEP was the least-bad way 
at the time we could think of to expose this functionality (and, the 
semantics were a mess), but no one was very happy about it, and I for 
one am thrilled that we came up with a no-syntax way to expose the 
required functionality.  So yes, I am absolutely certain that this is an 
improvement *for the goals we had in mind for this feature*.


On 10/30/2014 12:23 PM, David M. Lloyd wrote:
> On 10/30/2014 10:53 AM, Paul Sandoz wrote:
>>
>> On Oct 30, 2014, at 4:47 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>
>>>
>>> On 10/30/2014 03:02 PM, Paul Sandoz wrote:
>>>> Hi,
>>>>
>>>> I have, with the help of Brian, Doug and John, updated the
>>>> description of JEP 193: Enhanced Volatiles to reflect our current
>>>> thinking based on:
>>>>
>>>> - the prototype implementation in valhalla;
>>>> - performance measurements of that implementation; and
>>>> - investigations related to signature polymorphic methods and
>>>> invokedynamic.
>>>>
>>>> Thanks,
>>>> Paul.
>>>
>>> I seems that the changes are not propagated to the JEP yet,
>>> but there are available throught the corresponding bug:
>>>   https://bugs.openjdk.java.net/browse/JDK-8046183
>>>
>>
>> Doh! thanks, i forgot to send the link out,
>
> Wow, that's even *more* convoluted.  Are we *certain* that we are
> actually improving on the original proposal here?  It seems to me like
> everyone can't jump on the *handle bandwagon fast enough, even though it
> seems to be objectively more complex from concept (that human engineers
> want to understand) to API (the previously proposed API was very much
> cleaner and didn't rely on cross-your-fingers magic to make inefficient
> things become efficient) to implementation (to this day, relatively few
> people outside of Oracle even have a glimmer of understanding as to the
> rules and behaviors of these things).
>
> Are we *certain* this is an improvement?
>