[jmm-dev] jdk9 APIs

[Doug Lea]

On 08/12/2015 04:26 AM, Andrew Haley wrote:
> On 11/08/15 20:11, Doug Lea wrote:
>>
>> * 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.
>
> I think that's overly optimistic.  Given the difficulty of defining
> consume(ish) mode in a way that can be understood and the time to get
> HotSpot etc. to implement it correctly and efficiently is there a
> pressing need to do this now?
>

I'm not sure. Do we add loadLoadFence(Object ref) and get it over
with, or postpone? In light of the tendency for unresolved issues
to languish for many years, I'd like to at least carefully consider
the options.

Background: The idea is basically the same as already exists
for final fields: Even on processors otherwise requiring
load fences, they are not in general used when reading
a final field given a reference to an object containing one.
The underlying notion is that the processor/thread cannot
possibly speculate/reuse the field value given that it has
never seen that reference before, as assured by allocation and
GC protocols, along with store/release fences in constructors.
(Aside: this reasoning is not airtight until OOTA-related
issues are solved.) And further, once read, the value can be
used forever without re-reading. Well, except that actual JVMs
are more conservative about this, trying (imperfectly) to
cope with some cases of modifying final fields.

In RCU (the main use case driving consume mode), pretty much
the same holds except that the compiler is not aware of the
constraints, so doesn't know that it can elide the load fence,
and also doesn't know that it must discard any previous
values. So you have to tell it using a special load or fence
operation.  Most of the time, just using relaxed-loads would
work fine. But "most of the time" is not good enough.

I'm sure that there are plenty of cases out there where
Java programs also do this and get away with it because
the constraints happen to hold (even though not officially DRF).
And also buggy cases where they only sometimes hold, but would
be "fixed" via the use of a dependent-load fence/method.
Using an unscoped loadLoadFence or acquireFence would also fix,
but at greater cost on some processors. And 99+% of programmers
would accept the (possibly) further cost of using volatile here
to make their programs race-free by the usual criteria.

Given this background, I'm still not sure of the best
near-term choice:

Only a few extremely performance sensitive users on only some
platforms would be impacted if loadLoadFence(Object ref) were
defined but by default bound to acquireFence (Unsafe loadFence).

And conversely, only a few users would be impacted if
loadLoadFence(Object ref) did not even exist until
some time after RCU-like constructions became more
widespread.

I'm still thinking that the get-it-over-with option is
slightly better.

-Doug