API review of VarHandles

[David M. Lloyd]

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.

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