[jmm-dev] Update to description of JEP 193: Enhanced Volatiles
brian.goetz at oracle.com
Thu Oct 30 17:18:44 UTC 2014
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:
>>>> 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
>>> I seems that the changes are not propagated to the JEP yet,
>>> but there are available throught the corresponding bug:
>> 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?
More information about the jmm-dev