[jmm-dev] jdk9 APIs

[Doug Lea]

On 08/11/2015 02:01 PM, Jeremy Manson wrote:
> Just curious: which end users are jonesing for a Fences API?  I talk with a LOT
> of Java users, and it's *never* come up outside of the kinds of people on this list.
>

Good timing. I was about to post this set of misc follow-up notes
that mentions this.

* I don't want to get overly consumed about analogs of consume mode,
but it would be nice to deal with it in a way that is good enough not
to demand follow-up efforts. A different approach than getDependently
is to add an overloaded loadLoadFence method that restricts its scope
to loads from the given reference: void loadLoadFence(Object ref).
This is similar to the approach used in a previous (scrapped) version
of Fence APIs. JVMs could just equate it (as well as the no-arg
version) to acquireFence, but with some effort it could be implemented
to get better performance on some platforms. At the moment, this seems
like a better approach to me than VarHandle getDependently methods.

* VarHandles serve two roles: (1) providing access to CAS instructions
(plus the special RMW variants getAndAdd etc) that have no bytecodes
(2) supporting moded load/store access that in principle is the same
as people could arrange with the idiomatic application of Fences, but
in practice possibly different because JVMs might have an easier time
selecting instructions that combine fencing and access.

* The Fence API is geekier than VarHandles but no less necessary as
Unsafe goes away.  One audience is a small number of expert concurrent
programmers writing performance-sensitive code. As a general
observation, the more that such people understand their concurrent
algorithms, the more flexibility they need to implement them.  There
are a few constructions inside java.util.concurrent relying on them
(for example in StampedLock) that cannot otherwise be obtained in any
reasonable way. Which would be a problem without Fence API when
Unsafe goes away.

Another (mostly future) audience is Tool developers. Efforts to obtain
desired consistency properties via tool-based fence placements are
starting to approach plausibility. (Including a nice upcoming OOPSLA
paper "Declarative fence insertion" by Bender, Lesani, and Palsberg
that I don't see anywhere online yet.) We'd rather not see Java ruled
out of such efforts just because of the lack of access to
functionality that must exist in any Java implementation.

(Gratuitous aside: Fences are just flexible Semicolons.  Plain
semicolons outlived their usefulness, as bemoaned in the fun read:
"The Silently Shifting Semicolon"
http://snapl.org/2015/abstracts/full/Marino.html
http://www.cs.ucla.edu/~todd/research/snapl15.pdf)

-Doug