RFR: jsr166 jdk integration 2018-05

[Doug Lea]

Sorry Stuart, but I'm joining the no-modCount barrage.
To pick on the main issue...

On 05/16/2018 05:21 PM, Stuart Marks wrote:

> Suppose that a replaceAll() on another thread occurs, and that this is
> allowed. Does the application care whether the eventual printout
> contains partly new values and partly old values? How can you tell? It
> seems to me that this is more likely a programming error than a valid
> use case.

There are many data-races that are never detected via CME. CME was
designed to trap only some of them (and even at that, only heuristically
because modCount operations are not strictly ordered). ModCount
mechanics only deal with insertions and removals. Failing to catch a
race in replaceAll is no different than failing to catch one with
multiple concurrent setValues. It might be "nice" to adjust modCount on
any operation that might contribute to a datarace, but no reason to
single out replaceAll.

Having said this, I don't think that anything in the spec (vs default
implementation) prohibits an implementation of replaceAll from removing
and then re-inserting each element, in which case an implementation
would modify modCounts.

-Doug