API review of VarHandles

[Vitaly Davidovich]

On Friday, January 22, 2016, David M. Lloyd <david.lloyd at redhat.com> wrote:

> On 01/21/2016 07:32 PM, Brian Goetz wrote:
>
>>
>> I am baffled as to how the original language syntax proposal of using
>>> some trick like "xx.volatile.imaginaryMethod()" plus maybe one or two
>>> new bytecodes was considered unacceptable; looking at this API, I know
>>> that none of the aforementioned metrics were considered as acceptance
>>> criteria.  How did we get to this strange place?
>>>
>>
>> The path was actually quite obvious.
>>
>> The first question was, "OK, if the language had this magic syntax, what
>> bytecode would get generated?  And clearly it couldn't be Unsafe.  So
>> either a pile of new bytecodes, or an API, was needed that the front-end
>> compiler could generate against.
>>
>> Building APIs is generally preferable to new bytecodes, if an API can do
>> the job, and it turned out that it could do it just as well. Once we had
>> an API that met the requirements, it was pretty clear that language
>> syntax was not only unnecessary, but likely undesirable -- these exotic
>> access modes are power tools for power users (do you really want typical
>> users to reason about mixed volatile and relaxed access to variables?),
>> and they meet the needs of such users just fine (those users have been
>> using Unsafe all along, and this is clearly better and safer.)
>>
>> So it was not the either-or of "either an API *or* magic language
>> syntax", it was "either an API *or* syntax plus an API".  At which point
>> it was clear that the syntax didn't carry its own weight.
>>
>> I think this is a fine example of how the obvious idea was wrong, and
>> that most of the value of the initial syntax idea was framing the
>> problem space.  I'm glad we saw fit to jettison that when it ceased to
>> provide value.
>>
>
> I will contest the "APIs is generally preferable to new bytecodes, if an
> API can do the job" tack because it clearly doesn't track logically: most
> of the bytecodes in the JVM today could have been intrinsic API methods
> instead, e.g. Integer.add(int, int) and that sort of thing, but they
> clearly benefit from being bytecodes just from a simplicity standpoint.
> Having new bytecodes would certainly be simpler for javac; it would be
> simpler for the user also, especially the user of class generators and
> transformers (who by this point will now have to do some pretty bananas
> things to transform field references); I can only speculate that it would
> also be simpler for the interpreter/JIT itself as well because really
> you're just generating variations on getfield, *aload, etc.  But that is
> all besides the point.
>
> Even the API itself is really heavy and weird.  Experts need simple APIs
> more than anyone - especially those writing complex concurrent algorithms.
> They're the ones who aren't content to copy and paste blobs off of
> StackOverflow; rather they need to be able to prove that their program is
> correct, and the more complexity there is, the more difficult a task that
> becomes.  But even the premise that this API is experts-only is
> self-fulfilling: atomics and fences are quite useful to less advanced users
> too, especially simple get-and-set and CAS operations.  But there is little
> chance that this API is going to be used (or used correctly) by such users.


Experts need control more than anything else.  This is not to say they'll
be happy with a subpar API but control typically means lots of details so
there's a limit on how abstracted the API can be.  As mentioned, given the
API provides low level control one can build a higher level one for their
own needs.  The topic of ordering is complex by its nature, there's a
danger in hiding details in more abstract API.

>
> I have no problem with the methods present on the final product, in terms
> of the types of fences and operations.  But the setup procedures and
> concepts are far more complex than necessary, and I don't see this being
> useful to most users in its current shape as most people will flee from it.
>
> --
> - DML
>


-- 
Sent from my phone