RFR: jsr166 jdk integration 2018-05 (original) (raw)

Paul Sandoz paul.sandoz at oracle.com
Fri May 18 21:25:42 UTC 2018


Hi,

My CME budget is definitely in the red now :-) but i would like to attempt to summarize the different positions and suggest a solution. If that does not get traction i believe a graceful retreat is in order.

We appear to be in two different philosophical camps with regards to the interpretation of modCount (i suspect what both camps believe is compatible with what CME specifies [*]).

One camp believes AbstractList.modCount should only (on a best-effort basis) be incremented on structural modifications that change the size (even if the size change cannot be externally observed, like the example Doug presents).

The other camp believes there are other forms of modification that perturb the list leading to incorrect results since those forms can affect yet to be traversed elements. It is argued that bulk operations such as replaceAll and sort fit in this category, regardless of the implementation.

I hope that is an accurate representation, and if that is so here is a rough proposal bring those camps together. The specification of AbstractList.modCount could be modified as follows:

/**

Thoughts?

Paul.

[*] on CME

On May 16, 2018, at 4:04 PM, Doug Lea <dl at cs.oswego.edu> wrote:

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



More information about the core-libs-dev mailing list