API review of VarHandles
David M. Lloyd
david.lloyd at redhat.com
Fri Jan 22 13:11:01 UTC 2016
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
More information about the core-libs-dev